Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

firefox 70 #71580

Merged
merged 6 commits into from Oct 22, 2019
Merged

firefox 70 #71580

merged 6 commits into from Oct 22, 2019

Conversation

andir
Copy link
Member

@andir andir commented Oct 21, 2019

Motivation for this change

Firefox 70 is about to be released / has been released.

This bump depends on a bump of nss, sqlite & rust-cbindgen.

I made a separate PR to drop the abuse of RUSTC_BOOSTRAP=1 that has been merged into master already. Since this work depends on it I've included it here as well.

cc @vcunat @FRidh because they usually handle the staging workflow.

I targeted staging-next on purpose since this is likely to have a few Firefox security fixes (again). The reasoning for staging should be obvious. We have a pretty large rebuild due to sqlite and nss being touched.

I did build firefox on this branch and it looked fine for a while. I've not yet done intensive tests of the other things that will be rebuild in this branch. Usually the impact isn't that bad.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@ofborg ofborg bot added the 6.topic: rust label Oct 21, 2019
@ofborg ofborg bot requested review from edolstra, jtojnar and np October 21, 2019 20:43
@andir
Copy link
Member Author

andir commented Oct 21, 2019 •
edited

BTW, shouldn't we de-cloudflare Firefox 70?
It has DNS-over-HTTP(s) enabled and set to cloudflare DNS servers without any fallback.
On NixOS we could set them to config.networking.nameservers or something less vendor locky

I am absolutely in favor of that. I'd like to see an approach where we supply an enterprise policy that disables it.

@flokli
Copy link
Contributor

flokli commented Oct 21, 2019

Seems the other solutions documented here (probing for a canary domain, security.enterprise_roots.enabled) don't really apply, so enterprice policies might be the way to configure this.

According to their docs, this could be accomplished by adding a policies.json file into a distribution folder below the "installation directory". I didn't strace yet where our firefox looks for it.

The appropriate policy would be DNSOverHTTPS, and an example json is documented here: https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps

This also allows pointing to another DoH server, if sb. wanted to do that.

If we do this, we probably want to point firefox to look for that in the wrapper, so policies can be redefined without having to recompile firefox-unwrapped

@taku0 taku0 mentioned this pull request Oct 22, 2019
Merged
10 tasks
@FRidh FRidh changed the base branch from staging-next to staging October 22, 2019 07:20
@FRidh
Copy link
Member

FRidh commented Oct 22, 2019

Changing to staging because its not uncommon to get regressions due to sqlite.
(Note, however, that staging will anyway move to staging-next now so it won't matter...)

@FRidh FRidh merged commit 524e165 into NixOS:staging Oct 22, 2019
@vcunat
Copy link
Member

vcunat commented Oct 22, 2019

.mil-domains won't be resolved from Russia and Iran

For now, Firefox should only default to Cloudflare in "North America", besides displaying some opt-out dialogue, and the default resolver can prevent this anytime by blocking a canary domain. At least that's what I remember from discussions in relevant IETF places; I haven't investigated details of the defaults.

I'm certainly not a fan of Mozilla choosing this weird combination of defaults, and we could disable that in nixpkgs somehow (perhaps later). But in any case, the "war" is primarily about the masses who have no idea about DNS, and I don't think in our case the default applies to that many people.

@andir andir mentioned this pull request Oct 22, 2019
Merged
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@edolstra edolstra Awaiting requested review from edolstra

@jtojnar jtojnar Awaiting requested review from jtojnar

@np np Awaiting requested review from np

Assignees
No one assigned
Labels
6.topic: rust 10.rebuild-darwin: 501+ 10.rebuild-darwin: 5001+ 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@andir @flokli @FRidh @vcunat