This partially reverts https://dart-review.googlesource.com/c/sdk/+/154180.
The main mechanism for setting domain policy is still useful as we will
use this to avoid insecure connections for higher level protocols (such
as HTTP and gRPC).
We already knew Android does not enforce network policy at socket level
but it turns out iOS does not as well:
> ATS doesn’t apply to calls your app makes to lower-level networking
> interfaces like the Network framework or CFNetwork. In these cases,
> you take responsibility for ensuring the security of the connection.
This also resolves the need to fix
https://github.com/dart-lang/sdk/issues/43223 as we are no longer
enforcing the policy at socket level.
Change-Id: I3913da8ea39dac2c5a70fdabe442775b18cfd0c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161581
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Mehmet Fidanboylu <mehmetf@google.com>
The default behavior is controlled via a private configuration variable
settable by embedders (#_mayUseInsecureSocket). It is, by default,
configured to allow insecure connections. The domain configuration
itself is sent as a JSON encoded string which gets parsed once.
Embedders are expected to set these configurations before they run any
user code.
This is a re-work of https://dart-review.googlesource.com/c/sdk/+/142446
[dart:_http] Allow the embedder to prohibit HTTP traffic.
Change-Id: I4ccbd35da9ce25bf5f81ad4468111018d6af2f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154180
Commit-Queue: Mehmet Fidanboylu <mehmetf@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Strong mode requires package_config.json to opt-in packages, so
.dart_tool/package_config.json was added for tests which used .packages
file before.
Certain tests for handling custom foo.packages file were marked
to run only in weak mode (as package_config.json would supersede
custom .packages files).
Finally, certain tests were converted to multi-tests with expected
compile-time errors to reduce number of failing tests (compile-time
error was an expected behavior for those tests, just not reflected
in the test sources).
Change-Id: Id5a3140ee033c115221b2f4a0b12adf40b6de415
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154831
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This reverts commit bc4cb123a8.
Reason for revert: breaks crossword simarm tests https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-precomp-linux-debug-simarm_x64/2619
Original change's description:
> Reland "[ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process"
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
>
> This reverts commit 3849b5061c.
>
> Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,asiva@google.com
Change-Id: I649d94c668417f2edbfd7039fa5c876e10dc32fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154800
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
This reverts commit 3849b5061c.
Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit ffe258d2d4.
Reason for revert: Failures on bots
Original change's description:
> [ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
>
> Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: Idb1d24a4524bdc3ccfb199a82710f3c0d9db539a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154702
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This is a reland of 391d3bcdd8
The root cause of the failure is that the destination path uses forward
slashes as path separator.
This fix checks for forward slashes as a potential path separators.
If both forward and back slashes exist, the one closer to the end of the
path will be used to get the destination directory.
If any step fails, it will fall back to original copy.
Original change's description:
> File::Copy avoids direct copying on Windows
>
> There is a race condition for copying file on Windows, where CopyFile()
> returns success but data has not been populated into destination file.
> E.g process is killed or died in the middle.
>
> This cl will change File::Copy as
> 1. Copy file to a temp file in the same directory of destination file.
> 2. Rename the file to the target file.
>
> Bug: https://github.com/dart-lang/sdk/issues/42119
> Change-Id: I39b6d451f6ace970bc554501148259d33de232c7
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149667
> Commit-Queue: Zichang Guo <zichangguo@google.com>
> Reviewed-by: Zach Anderson <zra@google.com>
Bug: https://github.com/dart-lang/sdk/issues/42119
Change-Id: I58c3aa432d3f64bddb1deace4c9a1ceb2f0f5e16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151035
Commit-Queue: Zichang Guo <zichangguo@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
If a user program installs custom signal handling for SIGINT,
the DartDev instance may exit before its child, potentially causing
confusing behavior and 'zombie' children. By ignoring these signals in
DartDev, the DartDev instance will only exit once its child process
exits.
Fixes https://github.com/dart-lang/sdk/issues/42092
Change-Id: I04bf6d1f375b8bb3a4f7022f2c79ddde3bd5f414
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149643
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Jaime Wren <jwren@google.com>
If the Content-Length has been set by contentLength setter, manually
setting the header to the same value will lead to the header being
dropped, since _contentLength is not updated in set() method. The method
set() will erase the header and add back the header with new value. As
_contentLength is not updated, when it adds back the new header, it
looks at _contentLength (Which is not reset) and skips the addition (
_contentLength is the same as the new value, we had the header already).
Bug: https://github.com/dart-lang/sdk/issues/42369
Change-Id: I3fba7cc332bdff0ba56e602ac810fbaeb85d2606
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151427
Commit-Queue: Zichang Guo <zichangguo@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Changes:
Doing this always in precompiled mode meant increased data segment sizes
when CodeSourceMaps are stored, since encoded line/column information is
larger in the LEB-like encoding used. Now we only store column
information when we produce non-symbolic stacks, since the increased
space needed to store the columns is instead in DWARF sections and can
be stripped or elided.
Original description:
Previously, we passed line number information to the stack trace printer
and to DWARF by changing the non-special positions in the CodeSourceMap
to line numbers in precompiled mode. However, doing this lost column
information.
We get the column information back in the majority of cases by encoding
the line number and column information when neither is too large to pack
together into 30 bits. (Here, 20 bits for line and 10 bits for column.)
Otherwise, we just store the line information as before, though due to
using a bit to encode whether column info exists, it's reduced to 30
bits. If the line info is too big for that, we just return kNoSourcePos.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try
Change-Id: Ia8baee71468da6100a170fa305d03059ffd17f78
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151822
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit 7c34a80c11.
Reason for revert: This change seems to cause >2% code size regression
in flutter-release mode.
Original change's description:
> [vm/aot] Keep column information when possible for precompiled mode.
>
> Previously, we passed line number information to the stack trace printer
> and to DWARF by changing the non-special positions in the CodeSourceMap
> to line numbers in precompiled mode. However, doing this lost column
> information.
>
> We get the column information back in the majority of cases by encoding
> the line number and column information when neither is too large to pack
> together into 30 bits. (Here, 20 bits for line and 10 bits for column.)
> Otherwise, we just store the line information as before, though due to
> using a bit to encode whether column info exists, it's reduced to 30
> bits. If the line info is too big for that, we just return kNoSourcePos.
>
> Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try
> Change-Id: Id1c826f10871e2f304fa40a59d8b704404d3a2c9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151507
> Commit-Queue: Tess Strickland <sstrickl@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,sstrickl@google.com
Change-Id: I5cf97543d1ac2731bb27bdb58ae97af6f22f2cfb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-release-x64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-linux-product-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-release-simarm_x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151820
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Previously, we passed line number information to the stack trace printer
and to DWARF by changing the non-special positions in the CodeSourceMap
to line numbers in precompiled mode. However, doing this lost column
information.
We get the column information back in the majority of cases by encoding
the line number and column information when neither is too large to pack
together into 30 bits. (Here, 20 bits for line and 10 bits for column.)
Otherwise, we just store the line information as before, though due to
using a bit to encode whether column info exists, it's reduced to 30
bits. If the line info is too big for that, we just return kNoSourcePos.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try
Change-Id: Id1c826f10871e2f304fa40a59d8b704404d3a2c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151507
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
For proper crashpad integration, we need to generate a build ID, as the
build ID generated by crashpad if there is not one will be a simple XOR
of the first text page, which rarely changes for Dart snapshots.
Assembly snapshots already have a build ID included by the assembler, so
we currently only do this for ELF snapshots.
Currently the build ID is a 128-bit hash value that is four separate
32-bit hash values concatenated together. Those hash values come from
the contents of the VM and isolate .text and .rodata sections.
This change also contains work to separate out the concepts of sections
and segments in the ELF builder. Now, consecutive allocated sections
with the same write and execute flags are combined into a single PT_LOAD
segment when possible, which reduces the padding needed to ensure that
segments start on page boundaries in ELF snapshots.
Bug: https://github.com/dart-lang/sdk/issues/42020
Change-Id: I42a837dae665a3902d881b8d151b49ede87d6c67
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150625
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Instead, we just always add a BSS section and we add the ROData
sections for ELF snapshots in BlobImageWriter::WriteText() (similar
to how AssemblyImageWriter::WriteText() handles it for assembly).
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try
Change-Id: I87ce64037821ce10f2344964e7f379376c4538df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150937
Reviewed-by: Martin Kustermann <kustermann@google.com>
Migrate all the tests under standalone/ that include files under
sdk/sdk/ as part files to unblock the replacement of the unmigrated
sdk/sdk with the contents of the migrated sdk/sdk_nnbd.
Change-Id: Ia2e78bbff797f58244d94021d4b9616793bd641d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151036
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Zichang Guo