Re: u2f

[Kurt Roeckx]

On Mon, Jan 29, 2018 at 09:36:15AM -0700, J.C. Jones wrote:
> The only big U2F property I am familiar with that our support doesn't
> function for is Google Accounts, but I'm sure there are others. (It'd be
> interesting to get a list. I'll take that to a different thread, though)

I've spend some time trying to figure out some of the problems.

u2f-host pointed out that it couldn't find any U2F device. strace
showed it tried to open /dev/hidraw* and I needed to give myself 
write access to that file. After fixing that most things started
to work. It seems that chromium also stopped working and also
needed that permission change.

I was under the impression that
/lib/udev/rules.d/70-debian-uaccess.rules (part of the udev
package) should have fixed those permissions for me, and that that
used to work correctly. In stable I do get the correct
permissions.

The only other site I can't get working is facebook.

> Kurt - So the webauthn support isn't working on Linux for you? The only
> dependency is libudev, but there may be a hid profile somewhere needed. At
> least one person on IRC reported that it didn't work on arch until
> installing pcscd- but it was clearly something in the dependency tree, not
> pcscd itself. If you find the answer, let me know... We need to nail that
> down for the release notes.

I already had pcscd installed.


Kurt

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

Re: u2f

[Kurt Roeckx]

On 28/01/2018 21:03, Daniel Veditz wrote:

On Sat, Jan 27, 2018 at 6:35 PM, greyhorseman  wrote:


so we're talking 2 full releases and maybe 6-7 months? Am I at at least
close to correct.



If your question was truly "allow ME to use my ubikeys?" (emphasis mine)
then you can do that since Firefox 57, by changing some internal prefs.
https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/


I've tried this in 57 at that time and 58 this weekend on Linux without 
getting it to work. So for sites I need to log in that support U2F I 
currently need to use either the ESR version with the plugin or chromium.



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

Re: Ambient Light Sensor API

[Kurt Roeckx]

On 2017-04-26 11:01, Gervase Markham wrote:

On 25/04/17 16:46, Eric Rescorla wrote:

This suggests that maybe we could just turn it off


It would be sad to remove a capability from the web platform which
native apps have. Surely we can avoid this problem without being so
drastic? Is it right that one key use of this sensor is to see if the
person has the phone up against their face, right? If so, reducing to a
small number of quantized levels would do the trick.


As far as I know that's a different sensor which actually measures the 
proximity, not the light level, and usually just has 2 values.


I have no idea what the light sensor would all be used for. One of the 
few things I can think about is that you change the color theme like a 
GPS does for day and night settings, which does not require a lot of 
different levels.



Kurt

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

Re: Ambient Light Sensor API

[Kurt Roeckx]

On 2017-04-25 00:04, Martin Thomson wrote:
> I think that 60Hz is too high a rate for this.
>
> I suggest that we restrict this to top-level, foreground, and secure
> contexts.  Note that foreground is a necessary precondition for the
> attack, so that restriction doesn't really help here.  Critically,
> rate limit access much more than the 60Hz recommended for the
> accelerometer.  5Hz might be sufficient here, maybe even lower.

Note that they already talk about 2Hz being the rate they think is 
realistic to do their attack, and that 5Hz is probably an upper bound of 
their attack, so reducing it from 60 to 5 doesn't actually change 
anything and you would need to go even lower. You could for instance do 
something like only allowing it 1 time per minute, and require user 
approval for higher frequencies.


The other suggestion they have in their paper is to reduce the number of 
values you return, say 4 different values.



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

Re: Rationalising Linux audio backend support

[Kurt Roeckx]

On 2017-03-22 19:34, Botond Ballo wrote:

Now that this change has hit the release channel, we've started
receiving feedback from a wider range of users, a lot of it in bug
1345661 [1].

I believe the feedback in that thread brings some new information to
the table that we weren't aware of when this decision was made:

  - Based on the volume of the feedback we received, and the number
of duplicate bugs and so on, it appears that quoted telemetry data
underestimates the number of users who use ALSA. This is
corroborated by the fact that some of the affected distributions
disable telemetry in their Firefox packages.


I was under the impression that the telemetry said it was over 1%. If 
all of those start to report that it's broken, you will get a lot of 
reports. I also thinking breaking more than 1% of the users setup is way 
too high.


I've also reported that certain desktop environments don't come with 
pulseaudio by default.


The FAQ seems to suggest that telemetry is only enabled in the 
pre-release versions and not in the release versions. I assume there is 
a bias that is caused by this.



  - A number of users, particularly those in the audiophile and music
production / recording communities, report technical reasons for
preferring ALSA over PulseAudio.

  - We've had an offer from someone to volunteer to maintain the
ALSA backend (bug 1345661 comment 52 [2]).


Pulseaudio is really a layer between the application and alsa. If 
pulseaudio can do something it should be possible to do the same with 
alsa. But maybe pulseaudio makes certain things easier, I don't know.


In any case, alsa is supported on any linux version, while it's clear 
that for various reasons pulseaudio is not. It makes sense to me to 
support alsa, and maybe only alsa. As I understand it, if you only 
support alsa and the user is using pulseaudio you still end up using 
pulseaudio.



Kurt

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

Re: Reproducible builds

[Kurt Roeckx]

On 2016-07-18 20:56, Gregory Szorc wrote:


Then of course there is build signing, which takes a private key
and cryptographically signs builds/installers. With these in play, there is
no way for anybody not Mozilla to do a bit-for-bit reproduction of most
(all?) of the Firefox distributions at
https://www.mozilla.org/en-US/firefox/all/.


There is at least a section about this here:
https://reproducible-builds.org/docs/embedded-signatures/


Kurt

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

Re: Reproducible builds

[Kurt Roeckx]

On 2016-07-19 00:49, Mike Hommey wrote:

On Sun, Jul 17, 2016 at 09:38:31AM -0700, David Bruant wrote:

Out of curiosity, how has is the TOR team handled points 1 and 2?


I cannot answer for TOR, but I can answer for Debian, who also does
reproducible builds of Firefox.

1) is not addressed at all, and while the Firefox package is marked as
being reproducible, it's only because the chk files are not in the
Firefox package, but in the NSS package, which is separate, and is not
reproducible because of the .chk files.

2) Debian doesn't ship .tar.bz2 files, but .deb files, and the tools
that create those files deal with the reproducibility.

That being said, the packages that do reach Debian users are *not*
currently reproducible. Many of the required tools to make it happen are
not used to build normal packages. They are only used in a separate CI
that does two builds with a special toolchain and checks the results
are identical. (At least, that's my understanding of the current status)


It is at least the intention that all those toolchain changes end up in 
Debian itself and that packages can be build reproducible in Debian 
itself.  I know that at least dpkg recently added support for 
SOURCE_DATE_EPOCH, so we're making progress, I just don't know what the 
current state of everything is.


There was a talk at debconf about it, didn't have time to watch it yet:
http://meetings-archive.debian.net/pub/debian-meetings/2016/debconf16/Reproducible_Builds_status_update.webm


Kurt

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

Re: Reproducible builds

[Kurt Roeckx]

On 2016-07-17 18:38, David Bruant wrote:


 2) Timestamps of the files inside the .tar.bz2 package will differ, but 
untarring them and using a recursive diff will reveal no differences (except 
for the aforementioned .chk files)

The second point sort of solves them both. As part of making things verifiable, 
Mozilla could publish a program that makes byte by byte comparison only on 
files that matters after unzip. If they're not that important, .chk files could 
be ignored (blacklisted from the comparison). Same for file timestamps.
That would be acceptable IMHO since a backdoor cannot be hidden in .chk files 
or file timestamps (right?).

That could be called "comparable builds" and seems closer to something 
reachable than actually bit-equality.
This shifts the problem a bit because another programs verifies Firefox. 
However, this verifying program is a combination of gunzip + directory 
traversal + bit comparison and seems simple enough that it cannot be the target 
of being alterable.

Out of curiosity, how has is the TOR team handled points 1 and 2?


In Debian we have a similar problem with the timestamps in .deb files. 
We're actually making the .deb files bit identical.  See 
https://reproducible-builds.org/specs/source-date-epoch/ for how that's 
done.


A different problem you might have is that the order in .tar.bz2 files 
might not be identical, see:

https://wiki.debian.org/ReproducibleBuilds/FileOrderInTarballs

Note that Firefox in Debian can be build reproducible, I'm just not sure 
what is all needed for that.



Kurt

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

Re: Rationalising Linux audio backend support

[Kurt Roeckx]

On 2016-07-14 17:49, Mike Hoye wrote:

On 2016-07-13 10:31 PM, ajo...@mozilla.com wrote:

Our official Firefox builds on Linux support both PulseAudio and ALSA.
There are a number of additional contributed backends that can be
turned on at compile time, although contribution towards long-term
maintenance and matching feature parity with the actively developed
backends has been low. On Linux, we actively maintain the PulseAudio
backend but we also approach the PulseAudio developers when we see
issues in PulseAudio. The PulseAudio developers are generally good to
work with.

FWIW all of Arch, Fedora, Debian (including Raspian), (U/Ku/Xu)buntu,
Mint, OpenSUSE ship PulseAudio by default, and have for a long time.
You've got to work pretty hard to find a desktop linux distribution that
doesn't; even Gentoo and Android-x86 have it reliably available.


At least according to https://wiki.debian.org/PulseAudio, on Debian you 
don't get it by default when installing xfce or lxde.  But I guess you 
can argue what by default means.


I also wonder how this fallback thing works.  Things are linked to the 
pulseaudio library, but if the pulseaudio binary isn't installed things 
fall back to something else like alsa as far as I know.  Is this 
something the pulseaudio library does, or do you need to write the 
fallback yourself?



Kurt

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

Re: C++11 standard library support enabled on all Tier-1 platforms

[Kurt Roeckx]

On 2016-05-27 03:50, Nathan Froyd wrote:

Given the standard library's pervasive use of exceptions, and our
aversion to the same, if you are using a standard library header
that's not listed here:


Are there plans to start using C++ exception?  The wiki seems to suggest 
there are plans, but it was last modified in 2008.



Kurt


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

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

[Kurt Roeckx]

On 2016-05-18 10:10, Henri Sivonen wrote:

What do we need to do to reach a decision that it's indeed OK to treat
*run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
"patches not even welcome" kind of thing, considering that this may
lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded
performance relative to Mozilla-shipped 32-bit x86 Firefox?


That doesn't make sense, and seems to just have the opposite effect.  If 
runtime detection is non-optional only non-SSE2 is left.  If runtime 
detection is supported you wouldn't have degraded performance.



Kurt

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

Re: Split Gecko in standalone fuzzing-friendly programs.

[Kurt Roeckx]

On 2016-03-09 22:17, Boris Zbarsky wrote:

On 3/9/16 3:47 PM, decoder...@googlemail.com wrote:

Actually no. I adapted our gtests in less than an hour.


Does this have to do with the set of things they're testing, or the
style the tests are written in?


I think the point is that some tests make it easy to set up fuzzing 
based on them.  I think what makes it easy is that it has a some input 
data that it puts thru some API.  For instance read some JS and either 
just parse it or even try to run it.  Or read some image file and decode 
it, maybe even calling the needed functions to display it.


Clearly everything were you get (untrusted) data from somewhere it 
should be relatively easy to set up fuzzing for it, but maybe it should 
start with writing a test suite that takes that input and does something 
with it, and probably tries to expose it to as much as possible things 
as the real application would.


So maybe the question isn't about having standalone programs, but more 
about a test suite tries to deals with input data like a program that 
uses the API would do.



Kurt

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

Re: Does SSE2 usage still need to be conditional?

[Kurt Roeckx]

On 2016-02-03 14:23, Henri Sivonen wrote:

As for the consequences of requiring SSE2 unconditionally, I'm
personally more worried about a conflict with Linux distros that don't
already require SSE2 (even if near 100% of their users actually had
SSE2-enabled hardware; this concern is not about the actual numbers)
than about dropping support for XP boxes. Curiously, Fedora seems to
document that llvmpipe requires SSE2 as if the distro as a whole
didn't. I wonder if there actually exist non-SSE2 boxes with
Gnome3-compatible OpenGL on the GPU. Ubuntu also relies on llvmpipe in
the absence of suitable GPU-base OpenGL support. This suggests that
the major distros are de facto pretty far along requiring SSE2, but I
don't know what their policies are and how unhappy they'd be about
Firefox requiring SSE2 (or how unhappy we'd be if distros shipped
de-optimized Firefox and users thought it works the same as the one
from Mozilla).


As far as I know in Debian i386 just changed it's default from i586 to 
i686 (+ cmov?):

https://lists.debian.org/debian-devel/2015/09/msg00589.html

There are some packages that do unconditionally use things like sse2, 
but they're usually specialized and you wouldn't run it on old hardware.


I have no idea what the situation with things like llvmpipe is.


Kurt

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

Re: FYI: e10s will be enabled in beta 44/45

[Kurt Roeckx]

On 2015-12-04 19:43, jmath...@mozilla.com wrote:

On Friday, December 4, 2015 at 11:08:08 AM UTC-6, Armen Zambrano G. wrote:

LastPass bring the browser to a crawl making it almost impossible to
use. If we have users using LastPass on the beta population using e10s
we're going to have a lot of people upset.


Not an issue since initial rollout to beta and release will be to users who do 
not have addons installed.


It said "exclude users who have a large number of addons installed", 
which clearly is different from "users who do not have addons installed".


Is it even possible to have no addons installed?  Firefox installed a 
number of them on it's own without asking me.



Kurt

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

Re: Thunderbird, the future, mozilla-central and comm-central

[Kurt Roeckx]

On 2015-11-30 22:11, Mitchell Baker wrote:

5.  Many inside of Mozilla, including an overwhelming majority of our
leadership, feel the need to be laser-focused on activities like Firefox
that can have an industry-wide impact.With all due respect to
Thunderbird and the Thunderbird community, we have been clear for years
that we do not view Thunderbird as having this sort of potential.


I currently don't see Mozilla having a focus or having an industry-wide 
impact.  I do see both Firefox and Thunderbird as having that potential.



Kurt

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