Typically, the interfaces involved don't need to use raw char/char16_t strings,
and hence can benefit from the additional safety of using the Mozilla string
classes.
In some places, this patch also changes some UTF-16 APIs to UTF-8 where the
implementations can never actually support UTF-16. This reduces the amount of
code and runtime conversion.
MozReview-Commit-ID: y8o5wLBohe
--HG--
extra : rebase_source : 130c8b77a98d21d5b9a0efeccae8861d89fa8f02
Bug 1275841 switched some IDL types from "string" to "AUTF8String".
This had the unintentional effect of breaking decryption of previously saved
passwords that contained special characters.
In particular, the AUTF8String type means XPConnect may convert any strings
using that type to UTF-16 when crossing XPConnect boundaries.
However, crypto-SDR.js (responsible for encrypting and decrypting for the
password manager) expects to do conversions between UTF-16 and UTF-8 itself.
What ends up happening is crypto-SDR.js decrypts a saved password and tries to
convert from UTF-8 to UTF-16, but fails because the decrypted text is already
UTF-16.
The solution is to use ACString instead of AUTF8String. ACString does not result
in automatic encoding changes, so the expectations of crypto-SDR.js are met
again, and lets SecretDecoderRing.cpp keep the benefit of working with smart
string types.
This change probably breaks passwords saved after Bug 1275841 landed and before
this patch landed, but the number of passwords this patch breaks is probably
much lower than the number of passwords that would be broken if this patch did
not land.
MozReview-Commit-ID: 6Z01zfwJ6t7
--HG--
extra : rebase_source : 514e78f2e1c2cef3b3692656b20daf3b068a4fee
Before this patch, nsPKCS12Blob::digest_read used size_forward to perform a size
check on a buffer. However, the entire set of {digest_open, digest_close,
digest_read, digest_write} was unnecessary because NSS provides this
functionality by default when using SEC_PKCS12DecoderStart. This patch
simplifies things by removing the extraneous implementations.
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 0cb2c16f484a81b2e77384564973b58ac2d10fb9
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 196449249eec75b8eb10e59662231c3f4e83c268
As of bug 1284946, nothing uses nsPSMBackgroundThread, so it's just dead code
that is removed by this patch.
MozReview-Commit-ID: 24HWFHIeCX9
--HG--
extra : rebase_source : 0cdf572fa2b742d9a78b6f099d8a2cf465813ccb
This function is an infallible alternative to nsIURI::GetSpec(). It's useful
when it's appropriate to handle a GetSpec() failure with a failure string, e.g.
for log/warning/error messages. It allows code like this:
nsAutoCString spec;
uri->GetSpec(spec);
printf("uri: %s", spec.get());
to be changed to this:
printf("uri: %s", uri->GetSpecOrDefault().get());
This introduces a slight behavioural change. Previously, if GetSpec() failed,
an empty string would be used here. Now, "[nsIURI::GetSpec failed]" will be
produced instead. In most cases this failure string will make for a clearer
log/warning/error message than the empty string.
* * *
Bug 1297961 (part 1b) - More GetSpecOrDefault() additions. r=hurley.
I will fold this into part 1 before landing.
--HG--
extra : rebase_source : ddc19a5624354ac098be019ca13cc24b99b80ddc
NSPR should generally be avoided in favour of modern C++ code.
This patch does not convert uses of the NSS Base64 functions. It does however
take the opportunity to switch over some IDL functions to use the safer Mozilla
string classes, and fixes Bug 1251050 along the way.
MozReview-Commit-ID: CM8g9DzIcnC
--HG--
extra : rebase_source : 9d07db1bcefc9d9ed6a1f7e102f5c01bd9caa522
enum classes are in general safer than plain enums, and as such should be
preferred.
MozReview-Commit-ID: 1FK89SNhdk4
--HG--
extra : rebase_source : 764c4855026c02d8c9e33ca33637fec54ea5ca31
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
The Mozilla string classes don't require manual memory management and
automatically keep track of length, making them a safer choice than raw C
strings.
MozReview-Commit-ID: EwCiiP9EhDr
--HG--
extra : transplant_source : %05%D4%B6s%C1%DBye%2C3%C3%85%DB%22%91h%B4%27%E1l
1. encrypt() and decrypt() are C++ only.
The only callers are in SecretDecoderRing.cpp, and binary add-ons aren't
supported anymore. So, there is no need for these methods to be defined in the
IDL, and they should be treated as private to the nsISecretDecoderRing
implementation.
2. nsISecretDecoderRingConfig has never been implemented.
The interface and implementation are currently just bloat. If there is a need
for specifying the window for prompts in the future, a better way can be devised
then.
MozReview-Commit-ID: 1wXCDTIBJA2
--HG--
extra : transplant_source : %D7%27%5E3%BF%E9%16%0E%A3%8B%E1%8E%ADj%3F%25%B3i%9Al
The interfaces defined within have basically nothing to do with Necko.
MozReview-Commit-ID: 5J4D3w61Yry
--HG--
rename : netwerk/base/nsISecretDecoderRing.idl => security/manager/ssl/nsISecretDecoderRing.idl
extra : transplant_source : %AAP%26%5D%DE%ED%F6Q%C4%5Eia%F1%84T%8D%A7E%8Aw