This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
This change removes the legacy libnssdbm database that we migrated away from since Firefox 60.
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password. It otherwise removes support for libnssdbm everywhere in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
... except when building the newly added tools/update-packaging,
which builds the mar tool as a standalone thing, and building signmar
as well causes complications.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
--disable-verify-mar is kept to still allow to disable mar verification in
the updater for debugging purpose.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
Avoid MinGW's _ftelli64() and _fseeki64() implementations because they
are unreliable.
Differential Revision: https://phabricator.services.mozilla.com/D36037
--HG--
extra : moz-landing-system : lando
The conditions under which verifymar is built were not aligned with what
kind of setups are actually doing something. For instance
--disable-signmar --enable-verify-mar was building the verifymar library
but not doing anything with it.
OTOH, building with --enable-signmar --disable-verify-mar did build it
but its code was eliminated at link time because it's unused.
Finally, the conditions between modules/libmar/verify/moz.build and
toolkit/mozapps/update/updater/updater-common.build weren't aligned and
broke some non-Linux tier-3 platforms. We remedy the latter by moving
the flags and libraries verifymar needs to verifymar, so that things
that link verifymar inherit them.
And while in the vicinity, replace a use of NSPR_LIBS with the
pseudo-library `nspr` which has the same effect.
Differential Revision: https://phabricator.services.mozilla.com/D34620
--HG--
extra : moz-landing-system : lando
Added defines to mar_extract.c, mar_read.c, bsdiff.c so they use the ISO C and C++ conformant name.
Ran clang format on bspatch.cpp and the files under modules/libmar except for nss_secutil.c and nss_secutil.h since they are copies of nss code.
Disallows files from referencing the same bytes in the content blocks of a MAR
file by storing a list of structs containing a file's byte offsets and lengths.
A list was chosen since the cap of 256 files wouldn't produce considerable
overhead when extracting/reading/searching/etc through the archive.
Removing the ability for a MAR file to reference the same content block
repeatedly seems like a better solution than what was suggested in the BLRG
report. (limiting the number of files or checking for overly large
decompressed files)
Allows us to prohibit this type of file bomb while only losing an attribute
of the MAR file format that wasn't being leveraged. The fix is applied in
mar_enum_items and mar_find_item so that the manifest the updater uses is
equally safeguarded as the mar host tool.
Differential Revision: https://phabricator.services.mozilla.com/D11706
--HG--
extra : moz-landing-system : lando
Summary:
Adds some missing braces on if structures
Adds a check for i being larger or equal to nb
Reviewers: rstrong
Reviewed By: rstrong
Bug #: 1468542
Differential Revision: https://phabricator.services.mozilla.com/D12193
--HG--
extra : rebase_source : 51a99f5376ed8877162e82b6c15f147df81981f8
Make CityHash64, CityHash64WithSeed, and CityHash64WithSeeds usable from C code
Remove unnecessary includes from mar_read.c as well
Add DisableStlWrapping to mar tool's moz.build to fix linkage break when
building in Windows with MSVC
Differential Revision: https://phabricator.services.mozilla.com/D10774
Only a single type of additional block has ever been defined for the MAR
archive format and only a single block of that type is needed per file.
Limiting ourselves to reading only that until we define more seems
sensible.
Move additionalBlockSize check before first fread
Add MAXADDITIONALBLOCKSIZE as a constant for checking block sizes
Differential Revision: https://phabricator.services.mozilla.com/D10797
Historically we built all our binaries in directories in the objdir, then
symlinked them into dist/bin. Some binaries needed to be copied instead
so that certain relative path lookups work properly, so we resorted to
sprinkling `NSDISTMODE=copy` around Makefiles.
This change makes it so we build PROGRAMs (not any other sort of targets)
directly in dist/bin instead. We could do the same for our other targets
with a little more work.
There were several places in the tree that were copying built binaries to
some other place and needed fixup to match the new location of binaries.
On Windows pdb files are left in the objdir where the program was
originally linked. symbolstore.py needs to locate the pdb file both to
determine whether it should dump symbols for a binary and also to copy
the pdb file into the symbol package. We fix this by simply looking for
the pdb file in the current working directory if it isn't present next
to the binary, which matches how we invoke symbolstore.py.
MozReview-Commit-ID: 8TOD1uTXD5e
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
Historically we built all our binaries in directories in the objdir, then
symlinked them into dist/bin. Some binaries needed to be copied instead
so that certain relative path lookups work properly, so we resorted to
sprinkling `NSDISTMODE=copy` around Makefiles.
This change makes it so we build PROGRAMs (not any other sort of targets)
directly in dist/bin instead. We could do the same for our other targets
with a little more work.
There were several places in the tree that were copying built binaries to
some other place and needed fixup to match the new location of binaries.
On Windows pdb files are left in the objdir where the program was
originally linked. symbolstore.py needs to locate the pdb file both to
determine whether it should dump symbols for a binary and also to copy
the pdb file into the symbol package. We fix this by simply looking for
the pdb file in the current working directory if it isn't present next
to the binary, which matches how we invoke symbolstore.py.
MozReview-Commit-ID: 8TOD1uTXD5e
--HG--
extra : rebase_source : 9140be949b206bb595d9188ce7e8357347ecd9a9