lgarron@, I wonder if you are the right person to investigate this.

 Issue 708336  has been merged into this issue.

I don't think we need to consider this a Security bug. Because roots are considered local, pinning is never set in the first place, therefore it's not a degradation of security.

Assuming we will open this bug, I'll refrain from sharing my personal views regarding what Fedora does. I will note that there are some other technical alternatives only in the most recent versions of NSS, but we've not yet been able to uprev the minimum Linux NSS version ( Issue 691261 ), although we'd have to depend on a much newer version to take advantage of them.

I think migrating off NSS may be the more expedient path, and do not think the failure to allow setting HPKP (given its significant risks) should be a Security bug at all.

I don't think we need to consider this a Security bug. Because roots are considered local, pinning is never set in the first place, therefore it's not a degradation of security.

Assuming we will open this bug, I'll refrain from sharing my personal views regarding what Fedora does. I will note that there are some other technical alternatives only in the most recent versions of NSS, but we've not yet been able to uprev the minimum Linux NSS version ( Issue 691261 ), although we'd have to depend on a much newer version to take advantage of them.

I think migrating off NSS may be the more expedient path, and do not think the failure to allow setting HPKP (given its significant risks) should be a Security bug at all.

In retrospect "HPKP" was the wrong word to use in the summary - if I'm understanding correctly, even preloaded pins aren't enforced, which seems problematic.

We intentionally don't enforce preloaded pins on a variety of platforms, so it's not a strict security issue in my mind.

Ah, ok then. Your analysis makes sense.

I don't think I can make a useful decision here.

How are Chromium builds for Fedora built and distributed?
If it's not an official Google build, Chromium should compile without preloaded HPKP unless the distributor takes responsibility to enable it carefully.

@lgarron: This is not about Chromium builds for Fedora. It would also apply to Google Chrome builds run on Fedora.

*Do* we have Google Chrome builds for Fedora?

yes

https://www.google.com/linuxrepositories/
https://support.google.com/chrome/answer/95346
https://support.google.com/chrome/a/answer/7100626?hl=en

I think I agree with rsleevi that this is not a Chrome security bug. It might be a Fedora security bug, though.

@Comment 15: Why do you say Fedora? What they're doing is perfectly legal (and supported by NSS developers, which I suspect is why David mentioned it)

There's a new trust attribute added in newer versions of NSS that indicate built-in or not, with the assumption that those not built-in will not set it, but the Linux dependency hell is why I suggested it's not a reliable signal.

If we ship an official build on Fedora, isn't it a bug that HPKP is useless?

If we don't consider it ours to fix, is ExternalDependency appropriate?

lgarron: I'm trying to separate out two things:

Whether it's a bug (it is) from whether it's a security bug (that's questionable).

It's currently marked Sec_Severity-High. I'm not sure how that's consistent with our lack of shipping static HPKP pinning on platforms that don't support updates (Android, iOS) and the HPKP bypasses when Microsoft's AUTHROOT updates (Windows). In my mind, Static-HPKP was "Best effort, where we can", given those statements.

I'm not opposed to treating it as a bug, and as much as I'd love to drive  Issue 691261  to hopefully make this easier to solve, that's not a priority. But I'm questioning the triage.

It sounds like there is a rough consensus emerging that this is not a high severity Chrome security bug, and may not be a security bug in Chrome at all. I'll drop the severity for now.

Looking at Firefox's behaviour here might be instructive. For example, could we implement the workaround in https://bugzilla.mozilla.org/show_bug.cgi?id=1324096 ?

@Comment 19: Oh, we know the solution. The problem is we can't depend on it with our current NSS dependencies. See Comment 7.

Mozilla ships a hermetic copy of NSS. For various reasons, we opted not to do this.

Thanks for the feedback. Taking the security restrictions off this one.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b7b0457e35ca5fa1ca4df84c493767d73cae3690

commit b7b0457e35ca5fa1ca4df84c493767d73cae3690
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Thu Dec 28 21:11:12 2017

Use PK11_HasAttributeSet on Linux to determine root status when available

NSS 3.30 introduced PK11_HasAttributeSet(), along with
CKA_NSS_MOZILLA_CA_POLICY, to determine whether or not a certificate is
part of the "built-in" set. This was introduced because some
distributions replace NSS's nssckbi.so with a redirect to a
distro-specific version which does not maintain the same properties as
the upstream Mozilla version.

Generally, this is a redirect to p11-kit, to allow multiple trust sources
(upstream, per-system, admin-defined, user-defined) to be integrated as if
they're a single store. Unfortunately, this breaks the detection logic
for whether or not a certificate is issued by a known root on Linux.

As Chromium does not yet require an NSS version >= 3.30, use dlsym to
detect the function, and if it's available, do the more expensive query
to determine whether or not a cert is a known-root, while keeping the
fallback to the existing path.

BUG= 707280 

Change-Id: I340dafe56e605515d2421c33cf1b05f9431f6126
Reviewed-on: https://chromium-review.googlesource.com/845095
Reviewed-by: Eric Roman <eroman@chromium.org>
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526325}
[modify] https://crrev.com/b7b0457e35ca5fa1ca4df84c493767d73cae3690/net/cert/known_roots_nss.cc

On a Fedora system with an NSS version >= 3.30, the site https://pinning-test.badssl.com/ should fail to load

On a Fedora system with an NSS version < 3.30, the site https://pinning-test.badssl.com/ should load (due to it being treated as a local anchor)

This doesn't change the runtime dependencies for Chrom[e/ium] on such systems to require >= 3.30, hence the need to determine which version of nss. https://apps.fedoraproject.org/packages/nss indicates that Rawhide, 27, and 26 should all be shipping 3.34