Apple Notary Service and Debugging Impact
Please take a look if you debug Firefox on macOS. Apple's notary service[1] is a new way to sign macOS applications that has some security benefits[2] and provides a slight user experience improvement[3] when users download the application and run it for the first time. Specifically, the dialog users have to click through to start the application is less of a warning. We are working on adopting the service on bug 1470607, but I wanted to share how this will affect debugging and get some feedback. If an application is "notarized", starting with macOS 10.14, the OS will prevent debuggers from attaching to the application unless the user has disabled macOS system integrity protection (SIP)[4] which requires a reboot. This prevents debugging of the application with a debugger like lldb or gdb on a default system. Assuming the debugging restriction will _not_ apply to the Nightly channel, local builds, or automation builds, will this debugging restriction+workaround on official builds (Release, Beta, DevEd) be a problem for your workflow or in any way you can envision? Apple has stated that signing with the notary service will be required in a future macOS version. I think we can assume that this means an application that is not notarized will require special steps for first launch where the user may also have to click through dire security warnings. Today, launching Firefox for the first time on Mac already requires clicking through one warning. The bug includes a screenshot[3] showing how it will change with notarized builds. Thanks, Haik 1. https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution 2. Using the service A) submits the application to Apple to run malware checks on the binaries and B) requires setting some executable security flags known as Hardened Runtime. At present, Firefox mostly does not benefit from enabling Hardened Runtime for various reasons. Another benefit relates to how a single version of the application can be revoked, without having to revoke all versions signed with the same key. 3. https://bug1470607.bmoattachments.org/attachment.cgi?id=9036014 4. https://support.apple.com/en-us/HT204899 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPCOM Tidying Proposal
On Fri, Jan 11, 2019 at 11:59 AM Bobby Holley wrote:
> The idea is that we should gradually pass BasePrincipal around the codebase
> rather than nsIPrincipal, which would avoid the need to invoke Cast at the
> specific callsite. I have no objection to your proposed pattern in the
> interim if it results in simpler code, but I think we should aim higher for
> the desired end state.
>
The problem for me here seems to be uneven approaches to end states across
the codebase, which is kinda of what I was wondering about in laying out
those tasks. With nsIPrincipal, I have a BasePrincipal concrete(ish) class
to work with. When I was adding infallible SchemeIs via %{C++%} blocks to
nsIURI, that was about the only choice I had because nsIURI could directly
be nsStandardURI, nsSimpleURI, etc... As we wanting to move toward more
Base* (if abstract) C++ classes as the top level of interface work in C++
where possible?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: XPCOM Tidying Proposal
On Fri, Jan 11, 2019 at 11:30 AM Boris Zbarsky wrote:
> On 1/10/19 6:15 PM, Kyle Machulis wrote:
> > - Removal of [noscript] methods in interfaces in favor of direct calls
> via
> > Cast() where possible.
>
> This seems generally reasonably, though I'd like to put in a bit of a
> vote for the pattern I recently used for
> nsIPrincipal::IsSystemPrincipal, which looks like this:
>
> IDL:
>
> %{C++
>inline bool IsSystemPrincipal() const;
> %}
>
> C++ (in BasePrincipal.h):
>
>inline bool nsIPrincipal::IsSystemPrincipal() const {
> return BasePrincipal::Cast(this)->IsSystemPrincipal();
>}
>
> which avoids having the Cast() calls scattered all over the place...
>
The idea is that we should gradually pass BasePrincipal around the codebase
rather than nsIPrincipal, which would avoid the need to invoke Cast at the
specific callsite. I have no objection to your proposed pattern in the
interim if it results in simpler code, but I think we should aim higher for
the desired end state.
>
> > - Direct getters through Cast() where possible, infallible (also where
> > possible) otherwise.
>
> Yes, please.
>
> -Boris
> ___
> 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: XPCOM Tidying Proposal
On 1/10/19 6:15 PM, Kyle Machulis wrote:
- Removal of [noscript] methods in interfaces in favor of direct calls via
Cast() where possible.
This seems generally reasonably, though I'd like to put in a bit of a
vote for the pattern I recently used for
nsIPrincipal::IsSystemPrincipal, which looks like this:
IDL:
%{C++
inline bool IsSystemPrincipal() const;
%}
C++ (in BasePrincipal.h):
inline bool nsIPrincipal::IsSystemPrincipal() const {
return BasePrincipal::Cast(this)->IsSystemPrincipal();
}
which avoids having the Cast() calls scattered all over the place...
- Direct getters through Cast() where possible, infallible (also where
possible) otherwise.
Yes, please.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: XPCOM Tidying Proposal
On Fri, Jan 11, 2019 at 7:21 AM Nathan Froyd wrote: > > - Removal of [noscript] methods in interfaces in favor of direct calls > via > > Cast() where possible. > > - Direct getters through Cast() where possible, infallible (also where > > possible) otherwise. > > For avoidance of doubt, since I don't think we have a global Cast() > function, this is meant to refer to idioms like: > > > https://searchfox.org/mozilla-central/rev/b4ebbe90ae4d0468fe6232bb4ce90699738c8125/caps/BasePrincipal.h#136-142 > > and we'd prefer the explicit downcast from an interface pointer > (assuming the interface is [builtinclass]) and a C++-side getter, > rather than declaring the getter in the interface definition? > Yeah, this is why I sent this email. I'm finding unwritten rules about XPCOM cleanup that I'd like to formalize more. I've been fixing up docshell accesses using the Cast() idiom where I can. This has sometimes been to avoid having to cast the same docshell to 2-3 different interfaces over the course of the same method. It also makes it easier to whittle away at XPCOM interfaces that we may no longer need, but that we can't tell as such due to not knowing what's used where. When making some changes to nsIPrincipal and BasePrincipal, bholley also mentioned he preferred that style, wanting C++ ergonomics to live in C++. I'm not sure if there was more reasoning for that, I'll let him respond on that. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Building Firefox for arm64 windows got a lot easier
Hi all, On 11/01/2019 01.24, Mike Hommey wrote: > In the MSVC installer, choose the following extra components: > - Visual Studio C++ compiler and libraries for ARM64 > - Visual C++ ATL for ARM64 > - Visual C++ MFC for ARM64 I don't have the MFC for ARM64 libraries installed and I didn't encounter problems during the build. I guess they're not needed? I'm still building with WebRTC disabled though, not sure if it might require them. Gabriele signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPCOM Tidying Proposal
On Thu, Jan 10, 2019 at 6:15 PM Kyle Machulis wrote: > In an effort to bring Marie Kondo memes to dev-platform, I'd like to > propose an XPCOM tidying project. +1. > - Removal of [noscript] methods in interfaces in favor of direct calls via > Cast() where possible. > - Direct getters through Cast() where possible, infallible (also where > possible) otherwise. For avoidance of doubt, since I don't think we have a global Cast() function, this is meant to refer to idioms like: https://searchfox.org/mozilla-central/rev/b4ebbe90ae4d0468fe6232bb4ce90699738c8125/caps/BasePrincipal.h#136-142 and we'd prefer the explicit downcast from an interface pointer (assuming the interface is [builtinclass]) and a C++-side getter, rather than declaring the getter in the interface definition? > This would probably end up continuing making XPCOM interfaces look more > like a guide to shared parts between C++/JS than the template for all > access that is has been for years. +1. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
