```
2021-07-24 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* doc/rst/build_artifacts.rst, doc/rst/community.rst,
doc/rst/getting_started.rst, doc/rst/index.rst, doc/rst/more.rst,
doc/rst/releases/index.rst, doc/rst/releases/nss_3_64.rst,
doc/rst/releases/nss_3_65.rst, doc/rst/releases/nss_3_66.rst,
doc/rst/releases/nss_3_67.rst, doc/rst/releases/nss_3_68.rst:
Documentation: update and release notes for NSS 3.64 to 3.68
[e9236397be13] [tip]
2021-07-20 Robert Relyea <rrelyea@redhat.com>
* gtests/ssl_gtest/nss_policy.h,
gtests/ssl_gtest/ssl_auth_unittest.cc,
gtests/ssl_gtest/ssl_extension_unittest.cc,
gtests/ssl_gtest/tls_agent.cc, gtests/ssl_gtest/tls_agent.h,
gtests/ssl_gtest/tls_connect.cc, lib/ssl/ssl3con.c,
lib/ssl/sslimpl.h:
Bug 1720235 SSL handling of signature algorithms ignores
environmental invalid algorithms.
Our QA is quite extensive on handling of alert corner cases. Our
code that checks if a signature algorithm is supported ignores the
role of policy. If SHA1 is turned off by policy, for instance, we
only detect that late in the game. This shows up in our test cases
as decrypt_alerts rather than illegal_parameter or handshake_error
alerts. It also shows up in us apparently accepting a client auth
request which only has invalid alerts.
We also don't handle filtering out signature algorithms that are
illegal in tls 13 mode.
This patch not only fixes these issues, but also issues where we
proposing signature algorithms in server mode that we don't support
by policy.
This patch includes:
In gtests: 1) adding support for policy in ssl_gtests. Currently
both the server an client will run with the same policy. The patch
allows us to set policy on one and keeping the old policy on the
other.
2) Update extension tests which failed in tls 1.3 because the patch
now correctly rejects illegal tls 1.3 auth values. The test was
updated to use a legal auth value in tls 1.3 (so we are correctly
testing the format issue.
3) Update extension tests to handle the case where we try to use an
illegal value for tls 1.3.
4) add tests to ssl_auth_unittests.cc to make sure we can properly
connect even when several auth methods are turned off by policy
(make sure we don't advertize them on the client side, and that the
server doesn't select them when the client doesn't advertize them).
5) add tests to ssl_auth_unittests.cc to make sure we don't send
empty client auth requests when the requester only sends invalid
auth requests.
patch itself: 1) The handling of policy checks for ssl schemes were
scattered in various locations. I've consolidated them into a single
function. That function now checks for NSS_ALG_USE_IN_ANY_SIGNATURE
as if this is off by policy, we will fail if we try to use the
algorithm in a signature in any case. NSS now supports policy on all
signature algorithms, not just DSA, so we need to check the policy
of all the algorithms.
2) to support the policy check on the signature algorithms, I added
a new ssl_AuthTypeToOID, which also replaces our switch in checking
if the SPKI matches our auth type.
3) ssl_SignatureSchemeValid now accepts an spkiOid of
SEC_OID_UNKNOWN. To allow us to filter signature schemes based on
version and policy restrictions before we try to select a
certificate. This prevents us from sending empty client auth
messages when we are presented with only invalid signature schemes.
4) We filter supported algorithms against policy early, preventing
us from sending, or even setting invalid algorithms if they are
turned off by policy.
5) ssl ConsumeSignatureScheme was handling alerts inconsistently.
The Consume could send an allert in it's failure case, but the check
of scheme validity wouldn't sent an alert. The collers were
inconstent as well. Now ssl_ConsumeSignatureScheme always sends and
alert on failure, and the callers do not.
[c71bb1bedf7d]
```
Differential Revision: https://phabricator.services.mozilla.com/D120787
The accent-color computation right now chooses between black and white,
which is not ideal.
I tried to make it so that authors could choose the foreground colors in
the linked CSSWG issue from the comment, but that didn't go anywhere.
I think choosing a contrasting color that is in-line and contrasting
enough with the accent-color chosen by the page when darkening is better
than just black or white.
If we want the black-or-white behavior we can just change
layout.css.accent-color.target-contrast-ratio to something large enough.
https://accent-color.glitch.me/ is a nice playground to see this patch
in action.
Differential Revision: https://phabricator.services.mozilla.com/D120723
We expose these via CSS system colors, so this way we don't need to
rebuild the preference sheet when the link color is different.
Differential Revision: https://phabricator.services.mozilla.com/D120677
When reporting information about pretenuring it's helpful to be able to filter
out allocation sites with few allocations.
Differential Revision: https://phabricator.services.mozilla.com/D120716
Call MaybePushFloatContainingBlock() before some of
ConstructFramesFromItemList()'s caller to enforce the invariant that a
float containing block candidate is handled before processing its
children. Most of them handle nsIFrame::eXULBox frame like nsMenuFrame
that forbid float descendants.
The assertion condition only requires us to call
MaybePushFloatContainingBlock() if aParentFrame forbids float
descendants or is a float containing block, because it is a waste if
aParentFrame has nothing to do with floats, e.g. aParentFrame is
nsInlineFrame or nsCanvasFrame.
Note: ProcessChildren() calls ConstructFramesFromItemList() internally,
so adding the assertion in ConstructFramesFromItemList() is sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D120741
When we are in CreateColumnSpanSiblings(), there are floats in
nsFrameConstructorState::mFloatedList that are waiting to be added to
aInitialBlock once we leave scope of the float containing block.
However, since we are creating non-column-span continuations, which are
continuations of aInitialBlock, we should reparent the floats to these
continuations if their placeholders are the descendants of the
newly-created continuations.
multicol-span-float-002.html exercises
nsCSSFrameConstructor::ConstructBlock() and multicol-span-float-003.html
exercises nsCSSFrameConstructor::CreateIBSiblings().
Without this patch, multicol-span-float-002.html and
multicol-span-float-003.html still pass, but they trigger
```
ASSERTION: nsBlockFrame::CheckFloats: Explicit float list is out of
sync with float cache
```
1524382.html used to trigger the above assertions. Now it's fixed.
Differential Revision: https://phabricator.services.mozilla.com/D120105
Before this patch, a floating containing block (block frame)'s float
descendants are added to its mFloatedList in
~nsFrameConstructorSaveState() after returning from ProcessChildren().
This patch delays that by avoiding calling
MaybePushFloatContainingBlock() in ProcessChildren(), and move the call
one level up to ProcessChildren()'s callers so that the float
descendants are parented to the block frame after leaving the callers.
This is similar to how we handle the scope of abspos containing block.
This surely adds burden to some of the ProcessChildren() callers, but it
also unifies the float containing block scope for those callers
utilizing both ConstructFramesFromItemList() and ProcessChildren().
This doesn't change the behavior for now, but it is required by the next
part to correctly reparent the float descendants to the correct
non-column-span block continuations split by column-span wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D120104
Extract a helper to consolidate the if-else-if logic dealing with float
containing block, and adapt the callers to use it rather than
PushFloatContainingBlock().
This patch shouldn't change the behavior.
Note: In ConstructTableCell(), `!isBlock` is equivalent to
ShouldSuppressFloatingOfDescendants(cellInnerFrame) since
nsMathMLmtdInnerFrame is of eMathML type, so it's OK to just call
MaybePushFloatContainingBlock().
Differential Revision: https://phabricator.services.mozilla.com/D120103
This should make the logic around clearing a MessageChannel more obviously
correct by holding the mutex when accessing fields which are traditionally
guarded by the mutex. These lock calls shouldn't introduce performance issues
as the lock should be uncontended.
Differential Revision: https://phabricator.services.mozilla.com/D119354
This state was only used by the ProcessLink MessageLink implementation, and no
longer exists with the new PortLink implementation, so can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D119353
Now that PortLink is the only MessageLink implementation, it is no longer
necessary to support sharing a single `RefCountedMonitor` between multiple
MessageChannels, meaning that we can construct the monitor directly in the
`MessageChannel` constructor. The monitor still needs to be refcounted due to
being used by the PortLink as part of the listener implementation.
Differential Revision: https://phabricator.services.mozilla.com/D119350
This makes things generally more clear, and avoids a long list of initializers
in the MessageChannel constructor. In addition, some fields which are never
modified are marked as `const`.
Differential Revision: https://phabricator.services.mozilla.com/D119349
`self._job` is conditionally set. However, when it's not set, then
`if self._job is None` raises an exception.
Rather than having to check for `hasattr(self, "_job")`, defaulting
`self._job` to `None` seems more elegant and resolves the issue.
Differential Revision: https://phabricator.services.mozilla.com/D120754
In bug 1434542 I accidentally removed the part of
HeapThreshold::setSliceThreshold that clamped the threshold to the incremental
limit, causing these assertions to fail sometimes.
The use of uint64_t is because of potential overflow on 32 bit platforms as
commented in ToClampedSize().
Differential Revision: https://phabricator.services.mozilla.com/D120702
The codeql initialization process causes a loop in allocator
initialization that results in the inability to issue open()
calls due to function interception having begun set-up but
not completing it. (More details in bug.)
Differential Revision: https://phabricator.services.mozilla.com/D120521
When a WebSocket upgrade fails we currently do not
send any details of the error. As such it makes
it hard to figure out the real underlying issue.
Further some clients like curl are hanging and do
not immediately exit when the response has been
received. Specifying the Content-Length header
within the response fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D120575
Csoregi Natalia
Chris Peterson
Benjamin Beurdouche
Emilio Cobos Álvarez
Tomislav Jovanovic
Jens Stutte
Jon Coppeard
Randell Jesup
Michelle Goossens
Ting-Yu Lin
Joel Maher
Gijs Kruitbosch
Nika Layzell
Tim Giles
Mitchell Hentges
Kajal Sah
Emily McDonough
Marian-Vasile Laza
Tom Ritter
Jeff Muizelaar
Agi Sferro
Gavin Lazar Suntop
Henrik Skupin
Harry Twyford
Rob Wu
Karim Rahal
Thomas Wisniewski
Dan Minor
Sandor Molnar
Ryan Hunt
Andrei Oprea