In .NET Framework, TripleDESCryptoServiceProvider defaults to a feedback
size of 8, and TripleDESCng defaults to a feedback size of 64. The
static Create by default would return TripleDESCryptoServiceProvider,
thus the TripleDES from Create would have a default feedback size of 8.
This changes the default sizes of TripleDES to behave more
similarly to .NET Framework to make porting CFB code from Framework
easier.
The internal 3DES implementation (and thus
TripleDESCryptoServiceProvider, since that is a wrapper around the
internal implementation) now defaults to a feedback size of 8.
TripleDESCng and user-derived classes from TripleDES will continue to
use a feedback size of 64.
Co-authored-by: Kevin Jones <kevin@vcsjones.com>
Should workaround an issue we're seeing on AzDO while upgrading openssl@1.1 1.1.1g -> 1.1.1h: 'Error: Not a directory @ dir_s_rmdir - /usr/local/Cellar/openssl'
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
[release/5.0] Update dependencies from dotnet/arcade
- Avoid upgrading min version SDK
- Convert now-invalid C# in UnmanagedCallersOnly test to IL.
- Too many Ls.
Signed-off-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
This was only being done for OpenSSL 1.0. X509_new is actually available
to use in OpenSSL 1.0 and doesn't need to be re-defined:
https://www.openssl.org/docs/man1.0.2/man3/X509_new.html. That document
even says: "X509_new() and X509_free() are available in all versions of
SSLeay and OpenSSL".
The current libraries code doesn't contain an implementation of
local_X509_new. If we define X509_new as local_X509_new, it breaks the
build when it's being compiled non-portable against OpenSSL 1.0. See
https://github.com/dotnet/runtime/issues/42991 for complete details.
I was able to reproduce this on Fedora 29 when building using OpenSSL
1.0 headers. The error doesn't happen when building using OpenSSL 1.1,
since X509_new is never re-defined.
Fixes: #42991
Co-authored-by: Omair Majid <omajid@redhat.com>
- Resolve dependencies before counting to avoid the race
where its possible for the background thread to run before
the main thread resulting in singletons being resolved during
compilation (it's meant to be side effect free).
- We also avoid capturing the ExecutionContext on the background thread
to avoid capture of async locals.
Fixesdotnet/extensions#3566
Taken from 07e4459b6e
* make BrowserHttpMessage.Send throw PNSE (#42990)
* Throw PNSE on sync version of BrowserHttpHandler.Send
* Mark HttpClientHandler.Send as unsupported on browser
* Update reference source
* Add UnsupportedOsPlatform(browser) to more synchronous http apis (#43102)
* Update src/libraries/System.Net.Http/src/System/Net/Http/BrowserHttpHandler/BrowserHttpHandler.cs
Co-authored-by: Stephen Toub <stoub@microsoft.com>
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Port enable Alpine ARM support (#41982)
This change ports to release/5.0 enabling Alpine ARM support
in the lab build scripts packages and RID graph. It enables
CI and official builds.
* Port of #42096
There was an extra -c in the CMAKE_REQUIRED_FLAGS set for testing
HAVE_UNW_GET_ACCESSORS and HAVE_UNW_GET_SAVE_LOC that was breaking
build of coreclr under homebrew. The option was somehow making
these checks behave on ARM Linux, eveb though it is not clear to
me why, as it was just causing this option to be passed to the
compiler twice at different positions of the command line of
the cmake tests.
This change fixes it by using check_symbol_exists instead of
check_c_source_compiles, since just removing the duplicite -c
was resulting in the check failing on ARM / ARM64 Linux due
to a missing symbol from libunwind during linking.
Co-authored-by: Jan Vorlicek <janvorli@microsoft.com>
In recent builds of nano server BeginUpdateResource will return ERROR_CALL_NOT_IMPLEMENTED. ResourceUpdater needs to adapt to provide a good error experience.
Without this change the code still fails, but with a much less friendly error.
Co-authored-by: vitek-karas <vitek.karas@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
We're installing openssl@1.1 from Homebrew so we should check that version.
It looks like CI Macs don't set the /usr/local/opt/openssl symlink anymore.
Backport of https://github.com/dotnet/runtime/pull/43037 to release/5.0
We can now build runtime against the system libunwind using:
./build.sh -cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND
This allows Linux distributions that already ship a compatible version
of libunwind library to use that instead of carrying a duplicate in
.NET. This provides some benefits to them, including smaller build
sizes, slightly faster builds and fewer places to fix any
vulnerabilities
This functionality was already supported in .NET Core 3.1 and has
regressed since.
CoreCLR already handles `-DCLR_CMAKE_USE_SYSTEM_LIBUNWIND`, so no
changes are needed there.
The libraries build doesn't care about this cmake varibale, but cmake
itself fails if the variable is not used:
EXEC : CMake error : [runtime/src/libraries/Native/build-native.proj]
Manually-specified variables were not used by the project:
CLR_CMAKE_USE_SYSTEM_LIBUNWIND
So libraries just needs to check and ignore this variable.
The singlefilehost needs to link against libunwind too. Otherwise the
linker fails to resolve symbols, making the build fail:
/usr/bin/ld: runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib/libcoreclrpal.a(seh.cpp.o): in function `UnwindContextToWinContext(unw_cursor*, _CONTEXT*)':
dotnet/runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:176: undefined reference to `_ULx86_64_get_reg'
/usr/bin/ld: runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:177: undefined reference to `_ULx86_64_get_reg'
/usr/bin/ld: runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:178: undefined reference to `_ULx86_64_get_reg'
/usr/bin/ld: runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:179: undefined reference to `_ULx86_64_get_reg'
/usr/bin/ld: runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:180: undefined reference to `_ULx86_64_get_reg'
/usr/bin/ld: runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib/libcoreclrpal.a(seh.cpp.o): runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:181: more undefined references to `_ULx86_64_get_reg' follow
/usr/bin/ld: runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib/libcoreclrpal.a(seh.cpp.o): in function `GetContextPointer(unw_cursor*, ucontext_t*, int, unsigned long**)':
runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:227: undefined reference to `_ULx86_64_get_save_loc'
/usr/bin/ld: runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib/libcoreclrpal.a(seh.cpp.o): in function `PAL_VirtualUnwind':
runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:340: undefined reference to `_ULx86_64_init_local'
/usr/bin/ld: runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:351: undefined reference to `_ULx86_64_step'
/usr/bin/ld: runtime/src/coreclr/src/pal/src/exception/seh-unwind.cpp:360: undefined reference to `_ULx86_64_is_signal_frame'
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
Fixes: #42661
Co-authored-by: Omair Majid <omajid@redhat.com>
Add two directories to NATIVE_DLL_SEARCH_DIRECTORIES to single-file bundles:
1. The bundle exe directory
2. If the bundle extracts any files, the extraction directory
Fixes#42772
(cherry picked from commit 040301836d)
* DataContractSerialization doesn't work with TrimMode - link
DataContractSerialization has some Reflection "shim" methods that the ILLinker can't see through. This causes critical methods to be trimmed and applications to fail. These methods were put in place in .NET Core 1.0 when the full Reflection API wasn't available.
The fix is to remove these "shim" Reflection APIs and use Reflection directly.
Fix#41525Fix#42754
* add copyright header
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
Fix DAC thread context flags
The CONTEXT_* flags doesn't have the proper architecture specific bit set for the cross-OS/cross-arch DAC/DBI. This causes the thread contexts not to be copied correctly because of the way CORDbgCopyThreadContext (in coreclr\src\debug\shared\arm64\ primitives.cpp) masks/checks the context flags.
Fix x86 build: missing DT_CONTEXT_ALL
Co-authored-by: Mike McLaughlin <mikem@microsoft.com>
github-actions[bot]
Juan Hoyos
Juan Sebastian Hoyos Ayala
dotnet-maestro[bot]
Anirudh Agnihotry
John Salem
Maryam Ariyan
Larry Ewing
Drew Scoggins
Jan Vorlicek
David Mason
Alexander Köplinger
Andy Gocke
Thays Grazia
Mateo Torres-Ruiz
Matt Mitchell
Miha Zupan