Re: Upcoming changes to hg.mozilla.org access

[Andreas Tolfsen]

Also search Emilio Cobos Álvarez:

> On 11/2/19 12:53 PM, Andreas Tolfsen wrote:
>> Documentation changes have historically been well served by a “wiki
>> editing”/micro adjustments approach.  I wonder if there is anything
>> we can do with Phabricator to ease review requirements for documentation
>> changes from peers?
> 
> I think you can land patches without review even with Lando. I
> personally think that's acceptable for typo fixes / documentation
> updates / etc.


I just tried this on a documentation change and found the process
a little confusing, so I will share my experience here.

Phabricator will not let you self-review a change, but Lando will
as Emilio says, allow anyone with Commit Access Level 3 to _land_
changes unreviewed.

You have to click the grayed-out “View stack in Lando” link in the
right hand side column and dismiss these warnings:

> • Has a review intended to block landing.
> • Is not Accepted.
> • No reviewer has accepted the current diff.


It would be nice if Phabricator would let L3 authors self-review
so that the commit message could be rewritten to indicate that the
change was r=me.

The inability to self-review in Phabricator also means it’s not
possible to remove blocking reviewers automatically added by Herald
rules.

I hope this helps everyone trying to land typo correction,
documentations updates, and similar fixups.

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

Re: Upcoming changes to hg.mozilla.org access

[Kim Moir]

Just a note to let everyone know the hg.mozilla.org permissions change was
implemented this morning.  Thanks to everyone for the work that allowed us
to make our code repositories more secure.

Kim

On Fri, Nov 1, 2019 at 4:39 PM Kim Moir  wrote:

> The Engineering Workflow team enabled a hook in July which asked people to
> provide a reason for directly pushing to hg.mozilla.org.  Since it was
> enabled, we have seen the number of direct pushes decrease to a few per
> week.
>
> Enabling developers to use standard tools to land reviewed code through a
> secure pipeline also allows us to enable new workflow capabilities such as
> running static analyzers, linters, and code formatting tools, while making
> hg.mozilla.org more secure by reducing the number of people who can
> access it directly. It also paves the way for decommissioning
> mozilla-inbound, which will simplify our tree management and reduce
> infrastructure costs.
>
> On Nov 14, 2019, we intend to change the permissions associated with Level
> 3 access to revoke direct push access to hg.mozilla.org on
> mozilla-inbound, mozilla-central, mozilla-beta, mozilla-release and esr
> repos. If you do need a patch landed outside the Phabricator/Lando pipeline
> such as in the case of bustage, please use the #checkin-needed process
> https://wiki.mozilla.org/Sheriffing/How_To/Landing_checkin-needed_patches
> and contact the sheriffs in #sheriffs in Slack or IRC to land your patch.
>
> Specific teams will retain direct access to hg.mozilla.org (now called
> Level 4) such as Sheriffs and Release Management. We expect everyone else
> to use the Phabricator/Lando pipeline, but exceptions may be granted for
> special situations with director-level approval. If this applies to you,
> please follow up with your manager.
>
> The Engineering Workflow team is committed to supporting and improving the
> productivity of developers working on Firefox. If you have questions or
> need help with tooling, please reach out to us in the #phabricator Slack
> channel.
>
> Kim
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

intent to unship: HPKP (dynamic key pinning)

[Dana Keeler]

The breadth of the web public key infrastructure (PKI) is both an asset 
and a risk. Websites have a wide range of certificate authorities (CAs) 
to choose from to obtain certificates for their domains. As a 
consequence, attackers also have a wide range of potential targets to 
try to exploit to get a mis-issued certificate. The HTTP Public Key 
Pinning (HPKP) [0] header was intended to allow individual sites to 
restrict the web PKI to a subset as it applies to their domains, thus 
decreasing their exposure to compromised CAs.
Unfortunately, HPKP has seen little adoption, largely because it has 
proved to be too dangerous to use. There are a number of scenarios that 
can render websites inoperable, even if they themselves don't use the 
header. Chrome removed support for it in version 72 in January of this 
year [1]. According to our compatibility information, Opera, Android 
webview, and Samsung Internet are the only other implementations that 
support the header [2]. At this point, it represents too much of a risk 
to continue to enable in Firefox.
A related mechanism, DNS Certification Authority Authorization (CAA) 
[3], also allows websites to restrict which CAs can issue certificates 
for their domains. This has seen much larger adoption and does not 
suffer from the drawbacks of HPKP.
Earlier today, bug 1412438 [4] landed in Firefox Nightly [5] to disable 
HPKP via a preference. New HPKP headers will not be processed, and 
previously-cached HPKP information will not be consulted.
The static list of key pinning information that ships with Firefox is 
still enabled, and these pins will still be enforced.


[0] https://tools.ietf.org/html/rfc7469
[1] https://www.chromestatus.com/feature/5903385005916160
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
[3] https://tools.ietf.org/html/rfc6844
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1412438
[5] Coincidentally, version 72
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: motion path module level 1

[Boris Chiou]

Hi, All

As of Firefox 72, I intend to turn the preference of motion-path,
layout.css.motion-path.enabled, on by default on all platforms. Blink has
shipped it already but Webkit doesn't support it yet. There are some
properties defined in the spec, and I would like to ship part of them, to
match the behaviors in Blink:

1. offset-path: none | path()

2. offset-distance

3. offset-rotate

4. offset-anchor

Note: We have implemented ray() for offset-path
, but there are
still some critical spec issues not resolved, so I will add a new
preference to disable it on beta and release channels.


*Bug to turn on by default*:
https://bugzilla.mozilla.org/show_bug.cgi?id=1582554

*Spec*: https://www.w3.org/TR/motion-1/ (or
https://drafts.fxtf.org/motion-1/)

*DevTools*: We don't support DevTools for this motion-path now.

*WPT*:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/motion

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

Re: Upcoming C++ standards meeting in Belfast

[Botond Ballo]

My blog post about this standards meeting is now live:
https://botondballo.wordpress.com/2019/11/15/trip-report-c-standards-meeting-in-belfast-november-2019/.
It can also be found on Planet Mozilla.

Cheers,
Botond

On Tue, Oct 22, 2019 at 5:13 PM Botond Ballo  wrote:
>
> Hi everyone!
>
> The next meeting of the C++ Standards Committee (WG21) will be
> November 4-9 in Belfast, Northern Ireland.
>
> This meeting will be focused on bug fixing and stabilization for
> C++20, which has achieved feature-complete status at the last meeting.
> The C++20 draft contains a number of significant new features,
> including Concepts, Modules, Coroutines, Ranges, and default
> comparisons (Contracts has slipped to C++23), so undoubtedly there
> will integration and stabilization work to be done. In parallel, the
> Evolution groups will start looking at C++23 material. A proposal for
> the committee's high-level direction for C++23 can be found here [1];
> some significant items there include contracts, networking,
> reflection, and pattern matching. I'd also like to call particular
> attention to the web_view proposal that is the subject of another
> dev-platform thread [2].
>
> If you're curious about the state of C++ standardization, I encourage
> you to check out my blog posts where I summarize each meeting in
> detail (most recent one here [3]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [4] and here [5]).
>
> I will be attending this meeting, splitting my time between the
> Evolution Working Group Incubator (which I've been roped into chairing
> at this meeting), and the Evolution Working Group itself (on days when
> the Incubator isn't running), perhaps also visiting the Reflection
> Study Group if time permits. As always, if there's anything you'd like
> me to find out for you at the meeting, or any feedback you'd like me
> to communicate, please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
> [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0592r3.html
> [2] 
> https://groups.google.com/d/msg/mozilla.dev.platform/HGjLpdUaLsI/qxjSXwqrAAAJ
> [3] 
> https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/
> [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-08
> [5] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: [css-transforms-2] Individual Transform Properties (i.e. translate, rotate, scale)

[Boris Chiou]

Hi, All

As of Firefox 72, I intend to turn the preference of individual transform
properties, layout.css.individual-transform.enabled
,
on by default on all platforms. Blink has implemented it behind the
experiment flag but Webkit doesn't support it yet. There are three
properties defined in individual transform properties: translate, rotate,
scale. Their rendering results should be equal to translate(), rotate(),
and scale() functions on transform property.

*Bug to turn on by default*:
https://bugzilla.mozilla.org/show_bug.cgi?id=1424900

*Spec*: https://drafts.csswg.org/css-transforms-2/#individual-transforms

*DevTools*: We don't support DevTools for individual transforms now.

*WPT*:

1.
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/individual-transform
2.
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/animation
3.
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/parsing

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