Re: Intent to Implement: adding vector effects non-scaling-size, non-rotation and fixed-position to SVG

2017-01-26 Thread Daniel Holbert 
On 1/3/17 4:48 PM, ktecrami...@gmail.com wrote:
>> e.g. It seems like introductory notes example could just use a
>> separate SVG element that had fixed positioning instead of needing to build
>> fixed-position into SVG.
> 
> By "introductory notes example" do you mean the example in following link?
> https://svgwg.org/svg2-draft/coords.html#VectorEffects 

I think that's what Jeff meant, yes.

(Basically, can authors already solve the problems that
"vector-effect:fixed-position" is intended to solve, by simply creating
two different  elements (in an HTML context), and styling one with
"position: fixed">?  Here's a simple demo with a floating fixed-position
legend, using that sort of solution:
https://jsfiddle.net/vv9gwemr/
)

Also, Jeff asked another important question -- have other browsers
expressed any intent to implement these features?

Also note that this feature is marked as "at-risk" of being dropped from
this version of the SVG2 spec:
"ISSUE 31: Values of vector-effect other than non-scaling-stroke and
none are at risk of being dropped from SVG 2 due to a lack of
implementations."
https://svgwg.org/svg2-draft/coords.html#issue31

Looks like that warning was added here:
https://github.com/w3c/svgwg/issues/186

If no other browsers are intending to implement it, then there's a
serious question of whether it's worth taking on this added code & the
increased complexity/attack-surface/bug-surface/maintenance-burden that
new features inevitably bring along, if web developers aren't going to
be able to use the feature on the web due to lack of support in other
browsers.

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

Re: Redirecting http://hg.mozilla.org/ to https://

2017-01-26 Thread Eric Rescorla 
Yes. Kill it with fire!

-Ekr


On Fri, Jan 27, 2017 at 7:17 AM, Gregory Szorc  wrote:

> It may be surprising, but hg.mozilla.org is still accepting plain text
> connections via http://hg.mozilla.org/ and isn't redirecting them to
> https://hg.mozilla.org/.
>
> On February 1 likely around 0800 PST, all requests to
> http://hg.mozilla.org/ will issue an HTTP 301 Moved Permanently redirect
> to https://hg.mozilla.org/.
>
> If anything breaks as a result of this change, the general opinion is it
> deserves to break because it isn't using secure communications and is
> possibly a security vulnerability. Therefore, unless this change causes
> widespread carnage, it is unlikely to be rolled back.
>
> Please note that a lot of 3rd parties query random content on
> hg.mozilla.org. For example, Curl's widespread mk-ca-bundle.pl script for
> bootstrapping the trusted CA bundle queried http://hg.mozilla.org/ until
> recently [1]. So it is likely this change may break random things outside
> of Mozilla. Again, anything not using https://hg.mozilla.org/ should
> probably be treated as a security vulnerability and fixed ASAP.
>
> For legacy clients only supporting TLS 1.0 (this includes Python 2.6 and
> /usr/bin/python on all versions of OS X - see [2]), hg.mozilla.org still
> supports [marginally secure compared to TLS 1.1+] TLS 1.0 connections and
> will continue to do so for the foreseeable future.
>
> This change is tracked in bug 450645. Please subscribe to stay in the loop
> regarding future changes, such as removing support for TLS 1.0 and not
> accepting plain text http://hg.mozilla.org/ connections at all.
>
> Please send comments to bug 450645 or reply to dev-version-control@lists.
> mozilla.org.
>
> [1] https://github.com/curl/curl/commit/1ad2bdcf110266c33eea70b895cb8c
> 150eeac790
> [2] https://github.com/Homebrew/homebrew-core/issues/3541
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Redirecting http://hg.mozilla.org/ to https://

2017-01-26 Thread Gregory Szorc 
It may be surprising, but hg.mozilla.org is still accepting plain text
connections via http://hg.mozilla.org/ and isn't redirecting them to
https://hg.mozilla.org/.

On February 1 likely around 0800 PST, all requests to http://hg.mozilla.org/
will issue an HTTP 301 Moved Permanently redirect to https://hg.mozilla.org/
.

If anything breaks as a result of this change, the general opinion is it
deserves to break because it isn't using secure communications and is
possibly a security vulnerability. Therefore, unless this change causes
widespread carnage, it is unlikely to be rolled back.

Please note that a lot of 3rd parties query random content on hg.mozilla.org.
For example, Curl's widespread mk-ca-bundle.pl script for bootstrapping the
trusted CA bundle queried http://hg.mozilla.org/ until recently [1]. So it
is likely this change may break random things outside of Mozilla. Again,
anything not using https://hg.mozilla.org/ should probably be treated as a
security vulnerability and fixed ASAP.

For legacy clients only supporting TLS 1.0 (this includes Python 2.6 and
/usr/bin/python on all versions of OS X - see [2]), hg.mozilla.org still
supports [marginally secure compared to TLS 1.1+] TLS 1.0 connections and
will continue to do so for the foreseeable future.

This change is tracked in bug 450645. Please subscribe to stay in the loop
regarding future changes, such as removing support for TLS 1.0 and not
accepting plain text http://hg.mozilla.org/ connections at all.

Please send comments to bug 450645 or reply to
dev-version-cont...@lists.mozilla.org.

[1]
https://github.com/curl/curl/commit/1ad2bdcf110266c33eea70b895cb8c150eeac790
[2] https://github.com/Homebrew/homebrew-core/issues/3541
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Exposing SSLStatus to WebExtensions (and possibly extending it)

2017-01-26 Thread Giorgio Maone 
Hello everybody,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1322748#c4 David Keeler
suggested to bring this issue up in a public forum in order to decide
how and how much to expose of the nsISSLStatus interface and its
dependencies to WebExtensions, considering that many Firefox add-ons use
it either to provide enhanced security UIs  or to enforce stricter
security policies tailored on specific use cases.

Additionally, exposing also ECDHE/DHE parameters has been asked for the
same reasons ( https://bugzilla.mozilla.org/show_bug.cgi?id=1312195 ).

The most natural place to provide WebExtensions with this data is, IMHO,
in webRequest.onBeforeSendHeaders or in an ad-hoc event (onConnect?)
which needs anyway to be called before any HTTPS payload is actually
exchanged on the wire.

Personally (i.e. for the purposes of the Tails Download and Verify
Extension which I maintain) I would be fine with a thin wrapper over
nsISSLStatus and nsIX509Cert, but platform developers, security guys and
other add-ons authors likely have different but hopefully reconcilable
views on this matter, therefore I'm cross-posting to dev-platform,
dev-security and dev-addons hoping for the best outcome.

Cheers

-- 
Giorgio Maone
https://maone.net


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

New macro: NS_INLINE_DECL_PURE_VIRTUAL_REFCOUNTING

2017-01-26 Thread Kartikaya Gupta 
Just a heads-up that I pushed bug 1312319 which adds a new
NS_INLINE_DECL_PURE_VIRTUAL_REFCOUNTING macro to nsISupportsImpl.h.
This macro just defines pure-virtual AddRef/Release functions. It's
intended for use if you're creating a non-nsISupports interface where
you want the implementing classes to be refcounted. There were already
a lot of classes in the tree that were doing this and I updated them
to use the macro. Going forward please use the macro instead of
manually adding AddRef/Release pure-virtual functions to your
interfaces.

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

Re: Adding Rust code to Gecko, now documented

2017-01-26 Thread David Teller 
Bug 1231711, but I never got to do it, unfortunately.

On 26/01/17 08:01, zbranie...@mozilla.com wrote:
> On Thursday, November 10, 2016 at 5:15:26 AM UTC-8, David Teller wrote:
>> Ok. My usecase is the reimplementation of OS.File in Rust, which should
>> be pretty straightforward and shave a few Mb of RAM and possibly a few
>> seconds during some startups. The only difficulty is the actual JS
>> binding. I believe that the only DOM object involved would be Promise,
>> I'll see how tricky it is to handle with a combo of Rust and C++.
> 
> Did you ever get to do this? Is there a bug?
> 
> zb.
> ___
> 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