test_sslrecords fails sometimes

Hi,
the test
HARNESS_VERBOSE=yes make TESTS=test_sslrecords test
fails sometimes:

$ uniq -c results
28 Okay
2 Failed
7 Okay
1 Failed
8 Okay
1 Failed
29 Okay

(28 times in row okay,  two times in row failed, …)
The output difference between "Okay" and "Failed" is
+#   Failed test 'In context empty records test'
+#   at ../test/recipes/70-test_sslrecords.t line 48.
in the failed case. The complete log for fail and pass.  Any ideas what might cause it?
This is on Debian-Hurd btw. The same test passed ~270 times in a row on Debian-x86_64.

Does it always fail in exactly the same way and at the same line?

On 2016-07-29 09:20:04 [-0700], mattcaswell wrote:

Does it always fail in exactly the same way and at the same line?

yes. "Failed test 'In context empty records test'" is the only thing
that fails.
If you diff bad vs good, you see:

-#   Failed test 'In context empty records test'
-#   at ../test/recipes/70-test_sslrecords.t line 48.
…
+Received client packet
+Packet length = 57
+Processing flight 4

Record 1 (client -> server)
Content type: APPLICATION DATA
Version: TLS1.2
Length: 52
[ENCRYPTED APPLICATION DATA]
[test
+]

+Forwarded packet length = 57
+Received client packet
+Packet length = 57
+Processing flight 5

Record 1 (client -> server)
Content type: ALERT
Version: TLS1.2
Length: 52

+Forwarded packet length = 57
but no additional information of why. I can provide multiple logs of
pass and fail it you want.
Sebastian

Please checkout and build the "test_sslrecords-debug" branch from my personal repo:
https://github.com/mattcaswell/openssl
Open 3 terminals. From the first enter:
HARNESS_VERBOSE=1 make TESTS="test_sslrecords" test
It should display instructions on what to enter in the other 2 terminals:
RUN ME FROM test DIR IN TERMINAL 2:
OPENSSL_ENGINES=../engines ../util/shlib_wrap.sh ../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../apps/server.pem -naccept 1 -cipher AES128-SHA
RUN ME FROM test DIR IN TERMINAL 3:
echo test | OPENSSL_ENGINES=../engines ../util/shlib_wrap.sh ../apps/openssl s_client -engine ossltest -connect localhost:4453

Please repeat the above steps until you see a failure, and the report back what you see in each of the three terminals. Thanks!

On 2016-07-30 03:11:46 [-0700], mattcaswell wrote:

Please repeat the above steps until you see a failure, and the report back what you see in each of the three terminals. Thanks!

This triggers less often. So I made a "while((1)) …" loop in all three
terminals with a GO/END label including a timestamp to put them together.
Here is one extracted run:
Terminal one:
|GO: Sat Jul 30 14:42:56 CEST 2016
|make depend && make _tests
|make[1]: Entering directory '/home/bigeasy/openssl/openssl-1.1.0-pre5'
|make[1]: Leaving directory '/home/bigeasy/openssl/openssl-1.1.0-pre5'
|make[1]: Entering directory '/home/bigeasy/openssl/openssl-1.1.0-pre5'
|( cd test;
|  SRCTOP=../.
|  BLDTOP=../.
|  PERL="perl"
|  EXE_EXT=
|  OPENSSL_ENGINES=.././engines
|    perl .././test/run_tests.pl test_sslrecords )
|
|#   Failed test 'In context empty records test'
|#   at ../test/recipes/70-test_sslrecords.t line 48.
|# Looks like you failed 1 test of 1.
|../test/recipes/70-test_sslrecords.t ..
|1..1
|Proxy started on port 4453
|RUN ME FROM test DIR IN TERMINAL 2:
|OPENSSL_ENGINES=../engines ../util/shlib_wrap.sh ../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../apps/server.pem -naccept 1 -cipher AES128-SHA
|Connection opened
|RUN ME FROM test DIR IN TERMINAL 3:
|echo test | OPENSSL_ENGINES=../engines ../util/shlib_wrap.sh ../apps/openssl s_client -engine ossltest -connect localhost:4453
|Received client packet
|Packet length = 184
|Processing flight 0
| Record 1 (client -> server)
|  Content type: HANDSHAKE
|  Version: TLS1.0
|  Length: 179
|  Message type: ClientHello
|  Message Length: 175
|    Client Version:771
|    Session ID Len:0
|    Ciphersuite len:64
|    Compression Method Len:1
|    Extensions Len:70
|
|Forwarded packet length = 189
|Received server packet
|Packet length = 1093
|Processing flight 1
| Record 1 (server -> client)
|  Content type: HANDSHAKE
|  Version: TLS1.2
|  Length: 61
|  Message type: ServerHello
|  Message Length: 57
|    Server Version:771
|    Session ID Len:0
|    Ciphersuite:47
|    Compression Method:0
|    Extensions Len:17
| Record 2 (server -> client)
|  Content type: HANDSHAKE
|  Version: TLS1.2
|  Length: 1013
|  Message type: Certificate
|  Message Length: 1009
| Record 3 (server -> client)
|  Content type: HANDSHAKE
|  Version: TLS1.2
|  Length: 4
|  Message type: ServerHelloDone
|  Message Length: 0
|
|Forwarded packet length = 1093
|Received client packet
|Packet length = 346
|Processing flight 2
| Record 1 (client -> server)
|  Content type: HANDSHAKE
|  Version: TLS1.2
|  Length: 262
|  Message type: ClientKeyExchange
|  Message Length: 258
| Record 2 (client -> server)
|  Content type: CCS
|  Version: TLS1.2
|  Length: 1
| Record 3 (client -> server)
|  Content type: HANDSHAKE
|  Version: TLS1.2
|  Length: 68
|  Message type: Finished
|  Message Length: 12
|
|Forwarded packet length = 346
|Received server packet
|Packet length = 254
|Processing flight 3
| Record 1 (server -> client)
|  Content type: HANDSHAKE
|  Version: TLS1.2
|  Length: 170
|  Message type: NewSessionTicket
|  Message Length: 166
| Record 2 (server -> client)
|  Content type: CCS
|  Version: TLS1.2
|  Length: 1
| Record 3 (server -> client)
|  Content type: HANDSHAKE
|  Version: TLS1.2
|  Length: 68
|  Message type: Finished
|  Message Length: 12
|
|Forwarded packet length = 254
|Connection closed
|Waiting for server process to close: 8545
|not ok 1 - In context empty records test
|Dubious, test returned 1 (wstat 256, 0x100)
|Failed 1/1 subtests
|

Test Summary Report

../test/recipes/70-test_sslrecords.t (Wstat: 256 Tests: 1 Failed: 1)

Failed test:  1

Non-zero exit status: 1

Files=1, Tests=1,  0 wallclock secs ( 0.04 usr +  0.00 sys =  0.04 CPU)

Result: FAIL

Failed 1/1 test programs. 1/1 subtests failed.

Makefile:140: recipe for target '_tests' failed

make[1]: *** [_tests] Error 1

make[1]: Leaving directory '/home/bigeasy/openssl/openssl-1.1.0-pre5'

Makefile:138: recipe for target 'tests' failed

make: *** [tests] Error 2

DONE: Sat Jul 30 14:43:02 CEST 2016

Terminal two:
|GO: Sat Jul 30 14:42:56 CEST 2016
|engine "ossltest" set.
|Using default temp DH parameters
|ACCEPT
|CONNECTION ESTABLISHED
|Protocol version: TLSv1.2
|Client cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:DHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:SCSV
|Ciphersuite: AES128-SHA
|Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
|No peer certificate
|Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
|Supported Elliptic Curves: X25519:P-256:P-521:P-384
|CONNECTION CLOSED
|   0 items in the session cache
|   0 client connects (SSL_connect())
|   0 client renegotiates (SSL_connect())
|   0 client connects that finished
|   1 server accepts (SSL_accept())
|   0 server renegotiates (SSL_accept())
|   1 server accepts that finished
|   0 session cache hits
|   0 session cache misses
|   0 session cache timeouts
|   0 callback cache hits
|   0 cache full overflows (128 allowed)
|DONE: Sat Jul 30 14:43:02 CEST 2016
Terminal three:
|GO: Sat Jul 30 14:42:56 CEST 2016
|engine "ossltest" set.
|depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
|verify error:num=20:unable to get local issuer certificate
|verify return:1
|depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
|verify error:num=21:unable to verify the first certificate
|verify return:1

CONNECTED(00000003)

Certificate chain

0 s:/C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=Test Server Cert

i:/C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=OpenSSL Test Intermediate CA

---

Server certificate

-----BEGIN CERTIFICATE-----

MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV

BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT

VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt

ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG

A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU

RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw

ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ

KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi

R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv

vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7

TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU

41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R

AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI

AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW

BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49

hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK

WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp

yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7

vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds

xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t

JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==

-----END CERTIFICATE-----

subject=/C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=Test Server Cert

issuer=/C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=OpenSSL Test Intermediate CA

---

No client certificate CA names sent

---

SSL handshake has read 1347 bytes and written 530 bytes

Verification error: unable to verify the first certificate

---

New, SSLv3, Cipher is AES128-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

SSL-Session:

Protocol  : TLSv1.2

Cipher    : AES128-SHA

Session-ID:<PHONE_NUMBER>05060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F

Session-ID-ctx:

Master-Key:<PHONE_NUMBER>05060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F000102030405060708090A0B0C0D0E0F

PSK identity: None

PSK identity hint: None

SRP username: None

TLS session ticket lifetime hint: 7200 (seconds)

TLS session ticket:

0000 - 0a 0b 0c 0d 0e 0f 10 11-12 13 0a 0b 0c 0d 0e 0f   ................

0010 - 0a 0b 0c 0d 0e 0f 10 11-12 13 0a 0b 0c 0d 0e 0f   ................

0020 - 76 e8 e8 05 c3 14 e0 5e-b1 37 96 69 e7 8f b4 94   v......^.7.i....

0030 - bc e7 ef 1e 79 58 8c 6f-38 32 fe b2 25 3f 2f ab   ....yX.o82..%?/.

0040 - 4a 97 79 22 8e 22 b3 9f-a0 0c fb 46 dc f8 05 f9   J.y".".....F....

0050 - 95 c8 b3 c1 5f 7b 2d 1a-42 3e b2 d1 3f 5c 1a 3f   ...._{-.B>..?.?

0060 - fe c7 41 a4 fd 0f 92 6e-1d 7b 27 ed 49 4f 1e 66   ..A....n.{'.IO.f

0070 - 01 c2 e0 ce df 2c 94 47-dd 02 d9 72 b7 92 81 29   .....,.G...r...)

0080 - 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f   ................

0090 - 10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f   ................

Start Time:<PHONE_NUMBER>

Timeout   : 7200 (sec)

Verify return code: 21 (unable to verify the first certificate)

Extended master secret: yes

---

DONE

DONE: Sat Jul 30 14:42:56 CEST 2016

All runs:
https://breakpoint.cc/ossl-tc-term-pass-fail/term1.txt
https://breakpoint.cc/ossl-tc-term-pass-fail/term2.txt
https://breakpoint.cc/ossl-tc-term-pass-fail/term3.txt
The extracted one iteration:
https://breakpoint.cc/ossl-tc-term-pass-fail/term1-one.txt
https://breakpoint.cc/ossl-tc-term-pass-fail/term2-one.txt
https://breakpoint.cc/ossl-tc-term-pass-fail/term3-one.txt
Sebastian

Hmmmm. This looks suspiciously like some problem on the s_client side. This test is setting up a communication between s_server and s_client with a perl proxy in the middle. The proxy's job in this case is to "fiddle" with some of the packets to set up various test scenarios and then check that the two ends of the communication behave as expected.
In this case s_client and s_server are supposed to successfully be able to establish a connection - and in fact they do. You can see in both the s_server and s_client logs (terminals 2 and 3 respectively) that even in the case where the test fails, they have in fact successfully established a connection. The next thing that is supposed to happen is that s_client is supposed to send some application data and then close down the connection cleanly by sending a close_notify alert. This data never gets sent, i.e. we are missing this bit when the test fails (as you noted above):
+Received client packet
+Packet length = 57
+Processing flight 4
+ Record 1 (client -> server)
+  Content type: APPLICATION DATA
+  Version: TLS1.2
+  Length: 52
+  [ENCRYPTED APPLICATION DATA]
+  [test
+]
+
+Forwarded packet length = 57
+Received client packet
+Packet length = 57
+Processing flight 5
+ Record 1 (client -> server)
+  Content type: ALERT
+  Version: TLS1.2
+  Length: 52
+
+Forwarded packet length = 57

The s_client command line looks like this:
echo test | OPENSSL_ENGINES=../engines ../util/shlib_wrap.sh ../apps/openssl s_client -engine ossltest -connect localhost:4453

The interesting bit here is the echo test | at the beginning. Once s_client successfully establishes it's connection it is supposed to read data from stdin and send it through to the server. In this case the string "test". Subsequently, after there is no more data to read from stdin, it is supposed to cleanly close down. For some reason that is not happening.
Given that this works on every other platform (AFAIK), I suspect some peculiarity in the way that Hurd is handling the pipe and presenting the stdin to s_client. Although why only this test is affected is a mystery to me.
As I don't have access to a Hurd system though, I'm not really sure how best to proceed.

On 2016-08-01 03:40:10 [-0700], mattcaswell wrote:

The interesting bit here is the echo test | at the beginning. Once s_client successfully establishes it's connection it is supposed to read data from stdin and send it through to the server. In this case the string "test". Subsequently, after there is no more data to read from stdin, it is supposed to cleanly close down. For some reason that is not happening.

So it might be a libc / kernel issue.

Given that this works on every other platform (AFAIK), I suspect some peculiarity in the way that Hurd is handling the pipe and presenting the stdin to s_client. Although why only this test is affected is a mystery to me.

:) Thanks for looking into this.

As I don't have access to a Hurd system though, I'm not really sure how best to proceed.

Hurd is not a primary Debian architecture so my motivation is quite low
now that it mostly builds. I will point the Debian Hurd porter(s) to this
and maybe they dig deeper.
However if you want hurd access, you probably can get one:
https://www.gnu.org/software/hurd/public_hurd_boxen.html
and I understand if you don't.
Sebastian

Ok. I'm going to keep this open, but move the milestone to post 1.1.0. Unless someone keen with some Hurd knowledge comes along it looks unlikely that this will get fixed in that timescale.

Is this still an issue?

I'm not a hurd user myself. I just digged into this as part of other hurd failures which got fixed. And from what Matt wrote here it did look like something that could openssl related. I reported this as a possible issue to the debian hurd maintainer and I have no idea if their proceeded.
If you want I could test the master branch and see how it goes. Other than that I have no objections if this gets closed because it does not look as an openssl issue.

I think we should close this. Its unlikely we are going to make much progress unless someone with some hurd knowledge and access comes along to help out. We can always reopen it at some later time if needs be.


How to use the echo web server framework

See https://github.com/labstack/echo

If the focus of this issue is performance, there is another framework called iris you can look into.


SimplePing behaving funny

I find that pinging a whole subnet will not report about 20% of the devices that should be there. Bigger numbers if the max concurrency count is higher.
When I do some logging inside [SimplePing readData], I see that all kinds of instances of Simple ping are receiving data from other pings. Somehow the SocketReadCallback gets called multiple times when data comes in. This might be related to this problem.
I'd love to solve this but might need a little extra help to fix it. Any ideas?
When I log who is receiving the data and where it came from, I get this:

start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
start pinging <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>
SimplePing(<IP_ADDRESS>) receiving data from <IP_ADDRESS>

Thanks for your feedback. I noticed that too and it's weird since they are executed on different threads. I will have a look into it as I have some free time. In the mean time please post here any findings


Api appears to return links that don't exist on the page

I'm testing with the website: https://www.20minutes.fr/
And the api I'm calling is: http://favicongrabber.com/api/grab/www.20minutes.fr
One of the results it returns is: https://www.20minutes.fr/favicons/android-chrome-96x96.png, but this link doesn't work and it doesn't exist in the source code of their page. Do you know why the api returns this link?

Yes, I know) this link from the manifest file https://assets-v.20mn.fr/manifest.json
<link rel="manifest" href="https://assets-v.20mn.fr/manifest.json">

Ah I understand now. Thank you for the fast response!


Authentication error after upgrading to 0.23.1

We've started seeing an authentication error in our project after we upgraded to 0.23.1, the issue also seems to be present in 0.24.0.  Reverting to 0.22.0 solves the issue.
We start seeing the following 404 error when running a spark application that uses NIO to access gcs files:
code:      0
message:   Error code 404 trying to get security access token from Compute Engine metadata for the default service account. This may be because the virtual machine instance does not have permission scopes specified.
reason:    null
location:  null
retryable: false
com.google.cloud.storage.StorageException: Error code 404 trying to get security access token from Compute Engine metadata for the default service account. This may be because the virtual machine instance does not have permission scopes specified.
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.translate(HttpStorageRpc.java:189)
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.get(HttpStorageRpc.java:339)
	at com.google.cloud.storage.StorageImpl$5.call(StorageImpl.java:197)
	at com.google.cloud.storage.StorageImpl$5.call(StorageImpl.java:194)
	at shaded.cloud_nio.com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:91)
	at com.google.cloud.RetryHelper.runWithRetries(RetryHelper.java:54)
	at com.google.cloud.storage.StorageImpl.get(StorageImpl.java:194)
	at com.google.cloud.storage.contrib.nio.CloudStorageFileSystemProvider.checkAccess(CloudStorageFileSystemProvider.java:614)
	at java.nio.file.Files.exists(Files.java:2385)
	at htsjdk.samtools.util.IOUtil.assertFileIsReadable(IOUtil.java:346)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:206)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:162)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:118)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:87)
	at org.broadinstitute.hellbender.engine.spark.datasources.ReadsSparkSource.getHeader(ReadsSparkSource.java:182)
	at org.broadinstitute.hellbender.engine.spark.GATKSparkTool.initializeReads(GATKSparkTool.java:390)
	at org.broadinstitute.hellbender.engine.spark.GATKSparkTool.initializeToolInputs(GATKSparkTool.java:370)
	at org.broadinstitute.hellbender.engine.spark.GATKSparkTool.runPipeline(GATKSparkTool.java:360)
	at org.broadinstitute.hellbender.engine.spark.SparkCommandLineProgram.doWork(SparkCommandLineProgram.java:38)
	at org.broadinstitute.hellbender.cmdline.CommandLineProgram.runTool(CommandLineProgram.java:119)
	at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMainPostParseArgs(CommandLineProgram.java:176)
	at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:195)
	at org.broadinstitute.hellbender.Main.runCommandLineProgram(Main.java:131)
	at org.broadinstitute.hellbender.Main.mainEntry(Main.java:152)
	at org.broadinstitute.hellbender.Main.main(Main.java:233)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.spark.deploy.SparkSubmit$.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:736)
	at org.apache.spark.deploy.SparkSubmit$.doRunMain$1(SparkSubmit.scala:185)
	at org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:210)
	at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:124)
	at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
Caused by: java.io.IOException: Error code 404 trying to get security access token from Compute Engine metadata for the default service account. This may be because the virtual machine instance does not have permission scopes specified.
	at shaded.cloud_nio.com.google.auth.oauth2.ComputeEngineCredentials.refreshAccessToken(ComputeEngineCredentials.java:137)
	at shaded.cloud_nio.com.google.auth.oauth2.OAuth2Credentials.refresh(OAuth2Credentials.java:160)
	at shaded.cloud_nio.com.google.auth.oauth2.OAuth2Credentials.getRequestMetadata(OAuth2Credentials.java:146)
	at shaded.cloud_nio.com.google.auth.http.HttpCredentialsAdapter.initialize(HttpCredentialsAdapter.java:96)
	at com.google.cloud.http.HttpTransportOptions$1.initialize(HttpTransportOptions.java:157)
	at shaded.cloud_nio.com.google.api.client.http.HttpRequestFactory.buildRequest(HttpRequestFactory.java:93)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.buildHttpRequest(AbstractGoogleClientRequest.java:300)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.get(HttpStorageRpc.java:337)
	... 32 more
ERROR: (gcloud.dataproc.jobs.submit.spark) Job [cb87810a-0133-42b3-a954-363b62adce39] entered state [ERROR] while waiting for [DONE].

Looking at the dependency updates in this project, it seems like one of the auth libraries updated to version 0.8.0.  Could that be the causing the issue?
Is there some new configuration setting we should be using in our gcloud project?  Any help would be appreciated.

@lbergelson from a quick scan of google-auth-client-java, it seems there's some code change  regarding compute engine credential in version 0.7.1. Can you help check whether you could repro this issue with auth 0.7.1 ? (I  saw you use gradle, so I assume simply declaring auth 0.7.1 as an explicit compile dependency should override auth 0.7.0)

@neozwu I tried running with 0.22.0 but forcing the version of auth to 0.7.1, and was unable to reproduce the error that way.  I also tried forcing 0.8.0 and wasn't able to reproduce the problem that way either.  So either I'm building it wrong or it's not the auth library.  From running gradle dependencies it looks like the force is working though.
force 'com.google.auth:google-auth-library-oauth2-http:0.7.1'
force 'com.google.auth:google-auth-library-credentials:0.7.1'

@neozwu I was able to resolve the 404 error that @lbergelson reported by building a custom version of the latest master of google-cloud-java with the following patch applied:
diff --git a/pom.xml b/pom.xml
index 0a77a625b0..e0884bbf2d 100644
--- a/pom.xml
+++ b/pom.xml
@@ -131,10 +131,10 @@
     <api-client.version>1.22.0</api-client.version>

     <api-common.version>1.1.0</api-common.version>
-    <gax.version>1.8.1</gax.version>
-    <gax-grpc.version>0.25.1</gax-grpc.version>
+    <gax.version>1.8.0</gax.version>
+    <gax-grpc.version>0.25.0</gax-grpc.version>
     <generatedProto.version>0.1.19</generatedProto.version>
-    <google.auth.version>0.8.0</google.auth.version>
+    <google.auth.version>0.7.0</google.auth.version>
     <grpc.version>1.6.1</grpc.version>
     <guava.version>20.0</guava.version>
     <http-client.version>1.22.0</http-client.version>

So, it's very likely that the culprit is the google-auth-client-java change in 0.7.1 that @neozwu pointed out (https://github.com/google/google-auth-library-java/releases/tag/v0.7.1)

So it seems like the reason that I wasn't able to reproduce the issue by forcing 0.7.1 was that we're using the shaded jar, so the force statement wasn't actually replacing the dependencies.

Any suggestions on how we could go about dealing with this issue? Does anyone think that the hardcoded IP address added in https://github.com/google/google-auth-library-java/pull/110/files could be the cause?

Does anyone have any input on this one?  It's important to us that we be able to upgrade.

@lukecwik Could you comment on whether there could be any potential issues with hardcoded IP address for metadata server ? I saw you suggested an explicit IP vs domain name here.

GCE metadata server team specifically recommend using the IP address as a best practice to avoid DNS issues when contacting the metadata server.
Note that all of the Apiary client libraries have been using the fixed IP address for quite some time and to my knowledge have not experienced this issue.
The downside is that if the GCE metadata server team were to ever change the IP address of the metadata server, it would break everyone who hardcoded the address.

@neozwu @lukecwik Does anyone have any suggestions about how we can proceed?  Is there some information we can provide that would be helpful for debugging this?

Since you have a complicated setup, it would be best if you tried executing a simple program which only invokes the google-auth-library-java 0.7.1 from within the environment without adding additional dependencies which would exclude your network/host setup from the failure scenario or shell out and use curl to contact the metadata server from your application and log what you get back using the IP address directly. If a much simpler application/shelling out works means that you have a dependency/configuration of java issue going on.
If you exclude the host/network setup from the failure condition, then comparing the detailed maven dependency tree of the working and broken versions could help. For every library that changed, try doing a strict override on the dependency change on only the one specific library to narrow it down to which one is causing the failure.

I was able to reproduce the same exact error running gatk PrintReadsSpark on a fresh Dataproc cluster with no special configuration applied. This suggests cluster/firewall misconfiguration may not be the problem.
My repro's very short:
package repro_package;

import org.apache.spark.SparkConf;
import org.apache.spark.api.java.JavaSparkContext;
import com.google.cloud.storage.contrib.nio.CloudStorageFileSystem;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.ArrayList;

public class Main {

  final String cluster = "jps-test-cluster-2";

  public static void exists() {
    CloudStorageFileSystem fs = CloudStorageFileSystem.forBucket("jpmartin-testing-project");
    java.nio.file.Path p = fs.getPath("/hellbender-test-inputs/CEUTrio.HiSeq.WGS.b37.ch20.1m-2m.NA12878.bam");
    boolean x = Files.exists(p);
    System.out.println("" + p + " exists: " + x);
  }

  public static Integer runRemotely() {
    exists();
    System.out.println("Hello.");
    return 1;
  }

  public static void main(final String[] args) {
    exists();
    ArrayList<Integer> l = new ArrayList<Integer>();
    l.add(1);
    l.add(2);
    final SparkConf sparkConf = new SparkConf().setAppName("repro_package").setMaster("yarn-client");
    final JavaSparkContext ctx = new JavaSparkContext(sparkConf);
    ctx.parallelize(l, l.size()).map(i -> runRemotely());
    System.out.println("Done.");
  }
}

That's great @jean-philippe-martin -- now we're getting somewhere! Can you test whether the error goes away if you build a custom google-cloud-java shaded jar with google.auth.version downgraded to 0.7.0, as described in https://github.com/GoogleCloudPlatform/google-cloud-java/issues/2453#issuecomment-331276331?

From your simple application, try shelling out and sending a curl request by using the raw IP address and the non IP address version:

curl "http://<IP_ADDRESS>/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
curl "http://metadata/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"

CloudStorageFilesystem is part of google-cloud-java, though, it counts. I can try directly shelling out but surely this is already covered by your tests and is going to work.

I can confirm that shelling out from the app works as expected (and so does directly ssh'ing to the Dataproc cluster nodes).

One difference (not sure if relevant) is that Files.exists (using CloudStorageFileSystems) fails with the new library when running on the local machine, but passes with the older version.

Can you dump the verbose version of your dependency tree?

Sure, @lukecwik, here is what I have.  No problems before doing that.
DIF
diff --git a/pom.xml b/pom.xml
index c2fc611..43cc0ee 100644
--- a/pom.xml
+++ b/pom.xml
@@ -19,7 +19,7 @@
         <maven.compiler.source>1.8</maven.compiler.source>
         <maven.compiler.target>1.8</maven.compiler.target>

-        <google-api-client.version>1.22.0</google-api-client.version>
+        <google-api-client.version>1.23.0</google-api-client.version>
     </properties>

     <dependencyManagement>
@@ -103,6 +103,11 @@
         </dependencies>
     </dependencyManagement>
     <dependencies>
+        <!--<dependency>
+            <groupId>org.mongodb.scala</groupId>
+            <artifactId>mongo-scala-driver</artifactId>
+            <version>2.1.0</version>
+        </dependency>-->
         <dependency>
             <groupId>com.google.guava</groupId>
             <artifactId>guava</artifactId>
@@ -133,11 +138,11 @@
             <artifactId>scala-library</artifactId>
             <version>2.11.7</version>
         </dependency>
-<!--        <dependency>
+        <dependency>
             <groupId>org.apache.spark</groupId>
-            <artifactId>spark-mlib_2.11</artifactId>
+            <artifactId>spark-mllib_2.11</artifactId>
             <version>${spark.version}</version>
-        </dependency>-->
+        </dependency>
         <dependency>
             <groupId>org.apache.spark</groupId>
             <artifactId>spark-yarn_2.11</artifactId>
@@ -196,11 +201,11 @@
                 </exclusion>
             </exclusions>-->
         </dependency>
-        <!--<dependency>
+        <dependency>
             <groupId>com.google.apis</groupId>
             <artifactId>google-api-services-analyticsreporting</artifactId>
             <version>v4-rev116-1.23.0</version>
-        </dependency>-->
+        </dependency>
         <dependency>
             <groupId>com.google.api-client</groupId>
             <artifactId>google-api-client</artifactId>

Should also note I only get the 404 when running locally. Running the job from DataProc works fine. :frowning_face:

We also ran into authentication issues. The issue was exposed when updating to google-api-client.version 1.23.0:
Caused by: com.google.api.client.http.HttpResponseException: 404 Not Found
Not Found
	at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1070)
	at com.google.api.client.googleapis.batch.BatchRequest.execute(BatchRequest.java:241)
	at org.apache.beam.sdk.util.GcsUtil$3.call(GcsUtil.java:588)
	at org.apache.beam.sdk.util.GcsUtil$3.call(GcsUtil.java:586)
	at org.apache.beam.sdks.java.extensions.google.cloud.platform.core.repackaged.com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111)
	at org.apache.beam.sdks.java.extensions.google.cloud.platform.core.repackaged.com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:58)
	at org.apache.beam.sdks.java.extensions.google.cloud.platform.core.repackaged.com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:75)
	... 3 more

I was able to isolate the commit that broke it, if it's any help:
https://github.com/google/google-api-java-client/commit/22e76833e8e02e5594fc949c749fbfbbd780fb2f
Maybe it's better for me to post that as an issue on that repo?

@andreamlin - sure thing! I made https://github.com/google/google-api-java-client/issues/1073.

@lukecwik Anything we can do to move this forward?

Everyone - we are going to do a release today which pulls in google-auth-library-java version 0.9.0 which fixes the bug introduced in prior versions.

@garrettjonesgoogle Does the issue also apply to the Apiary vended libraries?
Can you explain what the fix is (it is unclear looking at the github commit history for google-auth-library-java)?

This is the fix: https://github.com/google/google-auth-library-java/pull/132
It doesn't apply to the Apiary vended libraries.

@garrettjonesgoogle That's excellent news.  Thanks for the update!

@jean-philippe-martin Would you be able to try out this fix using your repro above?

Looks like this is fixed in the auth library. Please reactivate if not.

I changed my repro program's build gradle to now include the new version:
compile 'com.google.cloud:google-cloud-nio:0.27.0-alpha:shaded'

Ran the program, and it failed again:
[Stage 0:>                                                          (0 + 1) / 2]17/11/08 23:10:06 WARN org.apache.spark.scheduler.TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, jps-test-cluster-2-w-0.c.jps-testing-project.internal, executor 1): com.google.cloud.storage.StorageException: Error code 404 trying to get security access token from Compute Engine metadata for the default service account. This may be because the virtual machine instance does not have permission scopes specified.
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.translate(HttpStorageRpc.java:189)
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.get(HttpStorageRpc.java:340)
	at com.google.cloud.storage.StorageImpl$5.call(StorageImpl.java:197)
	at com.google.cloud.storage.StorageImpl$5.call(StorageImpl.java:194)
	at shaded.cloud_nio.com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:91)
	at com.google.cloud.RetryHelper.run(RetryHelper.java:74)
	at com.google.cloud.RetryHelper.runWithRetries(RetryHelper.java:51)
	at com.google.cloud.storage.StorageImpl.get(StorageImpl.java:194)
	at com.google.cloud.storage.contrib.nio.CloudStorageFileSystemProvider.checkAccess(CloudStorageFileSystemProvider.java:614)
	at java.nio.file.Files.exists(Files.java:2385)
	at repro_package.Main.exists(Main.java:40)

For what it's worth, it seems I'm correctly using the new auth library:
$ gradle dependencies --configuration compile | grep 'auth'
|    |    |    |    +--- com.google.auth:google-auth-library-oauth2-http:0.9.0
|    |    |    |    |    +--- com.google.auth:google-auth-library-credentials:0.9.0
|    |    |    +--- com.google.auth:google-auth-library-credentials:0.9.0
|    |    |    +--- com.google.auth:google-auth-library-oauth2-http:0.9.0 (*)
|    |    |    +--- com.google.oauth-client:google-oauth-client:1.23.0
|    |    |    |    +--- com.google.oauth-client:google-oauth-client:1.23.0 (*)
     |    |    |    +--- org.apache.hadoop:hadoop-auth:2.2.0

and the new version of google-cloud:
$ gradle dependencies --configuration compile | grep 'google-cloud'
+--- com.google.cloud:google-cloud-nio:0.27.0-alpha
|    +--- com.google.cloud:google-cloud-storage:1.9.0
|    |    +--- com.google.cloud:google-cloud-core:1.9.0
|    |    +--- com.google.cloud:google-cloud-core-http:1.9.0
|    |    |    +--- com.google.cloud:google-cloud-core:1.9.0 (*)

If you'd like to suggest a way for me to share the whole program in a way that you can run it as well and see for yourself, I'm open to suggestions.

@anthmgoogle I don't seem to be able to reopen this issue myself, but perhaps it should be.

So our most recent assumption was that this error was being caused by a configuration issue in our projects, but we've now tested with different google projects that don't share the same owners or configuration and the error reproduces in both of them.
See https://github.com/broadinstitute/gatk/pull/3855 for the complete discussion.  It's unclear what we should do to continue debugging this.  @anthmgoogle Any suggestions?

If we can no longer reproduce, I suggest we close.

@anthmgoogle

If we can no longer reproduce, I suggest we close.

That is literally the opposite of what was said. We reproduced the bug and ran out of ideas for how to make the test not fail.

Apologies. Reactivating and reassigning.

@hzyi-google Unfortunately this issue still persists for us running on Google Dataproc using the latest google-cloud-java release (0.47.0-alpha:shaded) and the latest Dataproc image (1.2.34). Could you please re-open this issue? I don't think the compatibility issues between google-cloud-java and Google Dataproc have been resolved. Our project is stuck on an ancient fork of google-cloud-java 0.20.4-alpha because of it, and it's starting to cause major issues for us.
Thanks!
(@jean-philippe-martin pinging you as well on this)

Apologies that the issue still exists. I'll take a look again.

Here is what Dataproc team mentioned from an internal thread:

... can make use of the following init action to install newer versions of the GCS and BigQuery connectors onto their cluster. The latest versions of the connectors, 1.8.1 for the GCS connector and 0.12.1 for the BigQuery Connector, better isolate the API client libraries used by the connectors so that customers can bring their own versions of the API client libraries without interfering with the connector itself.

Please let me know if this helps.

@hzyi-google Thanks for the suggestion. I tried running with the updated GCS connector version by creating a Dataproc cluster using the following command:
gcloud dataproc clusters create droazen-test-cluster --initialization-actions gs://dataproc-initialization-actions/connectors/connectors.sh --metadata 'gcs-connector-version=1.8.1' --metadata 'bigquery-connector-version=0.12.1' --num-workers 4 --num-masters 1 --image-version 1.2

I then built a version of our toolkit that depends on com.google.cloud:google-cloud-nio:0.47.0-alpha:shaded (the newest release of google-cloud-java, which is what we're trying to update to). I still got an error, but it's different from the 404 error we've been getting all along:
=========== Cloud Dataproc Agent Error ===========
java.io.IOException: Error accessing: bucket: dataproc-8cbe9d51-94fb-4ad4-9c34-a283212c2ae6-us
	at com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl.wrapException(GoogleCloudStorageImpl.java:1857)
	at com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl.getBucket(GoogleCloudStorageImpl.java:1814)
	at com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl.getItemInfo(GoogleCloudStorageImpl.java:1763)
	at com.google.cloud.hadoop.gcsio.GoogleCloudStorageFileSystem.getFileInfo(GoogleCloudStorageFileSystem.java:1144)
	at com.google.cloud.hadoop.gcsio.GoogleCloudStorageFileSystem.exists(GoogleCloudStorageFileSystem.java:448)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.configureBuckets(GoogleHadoopFileSystemBase.java:1967)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystem.configureBuckets(GoogleHadoopFileSystem.java:69)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.configure(GoogleHadoopFileSystemBase.java:1915)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.initialize(GoogleHadoopFileSystemBase.java:1064)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.initialize(GoogleHadoopFileSystemBase.java:1027)
	at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2812)
	at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:100)
	at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2849)
	at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2831)
	at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:389)
	at org.apache.hadoop.fs.Path.getFileSystem(Path.java:356)
	at com.google.cloud.hadoop.services.agent.util.HadoopUtil.getFs(HadoopUtil.java:63)
	at com.google.cloud.hadoop.services.agent.util.HadoopUtil.download(HadoopUtil.java:70)
	at com.google.cloud.hadoop.services.agent.job.AbstractJobHandler.downloadResources(AbstractJobHandler.java:424)
	at com.google.cloud.hadoop.services.agent.job.AbstractJobHandler$StartDriver.call(AbstractJobHandler.java:543)
	at com.google.cloud.hadoop.services.agent.job.AbstractJobHandler$StartDriver.call(AbstractJobHandler.java:532)
	at com.google.cloud.hadoop.services.repackaged.com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
	at com.google.cloud.hadoop.services.repackaged.com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57)
	at com.google.cloud.hadoop.services.repackaged.com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1921)
	at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1904)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1420)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
	at com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:93)
	at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:972)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
	at com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl.getBucket(GoogleCloudStorageImpl.java:1808)
	... 29 more
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:91)
	at sun.security.validator.Validator.getInstance(Validator.java:179)
	at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:312)
	at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:171)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:184)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
	... 39 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
	at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
	at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
	at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:89)
	... 51 more
======== End of Cloud Dataproc Agent Error ========

I noticed, however, that we do have a copy of the GCS connector in our classpath. I tried excluding it from our jar completely, and got this error instead:
=========== Cloud Dataproc Agent Error ===========
java.lang.NullPointerException
	at com.google.api.client.util.SecurityUtils.loadKeyStore(SecurityUtils.java:84)
	at com.google.api.client.googleapis.GoogleUtils.getCertificateTrustStore(GoogleUtils.java:76)
	at com.google.cloud.hadoop.util.HttpTransportFactory.createNetHttpTransport(HttpTransportFactory.java:136)
	at com.google.cloud.hadoop.util.HttpTransportFactory.newTrustedTransport(HttpTransportFactory.java:146)
	at com.google.cloud.hadoop.util.CredentialFactory.getStaticHttpTransport(CredentialFactory.java:200)
	at com.google.cloud.hadoop.util.CredentialFactory.getCredentialFromMetadataServiceAccount(CredentialFactory.java:215)
	at com.google.cloud.hadoop.util.CredentialConfiguration.getCredential(CredentialConfiguration.java:75)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.configure(GoogleHadoopFileSystemBase.java:1875)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.initialize(GoogleHadoopFileSystemBase.java:1064)
	at com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase.initialize(GoogleHadoopFileSystemBase.java:1027)
	at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2812)
	at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:100)
	at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2849)
	at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2831)
	at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:389)
	at org.apache.hadoop.fs.Path.getFileSystem(Path.java:356)
	at com.google.cloud.hadoop.services.agent.util.HadoopUtil.getFs(HadoopUtil.java:63)
	at com.google.cloud.hadoop.services.agent.util.HadoopUtil.download(HadoopUtil.java:70)
	at com.google.cloud.hadoop.services.agent.job.AbstractJobHandler.downloadResources(AbstractJobHandler.java:424)
	at com.google.cloud.hadoop.services.agent.job.AbstractJobHandler$StartDriver.call(AbstractJobHandler.java:543)
	at com.google.cloud.hadoop.services.agent.job.AbstractJobHandler$StartDriver.call(AbstractJobHandler.java:532)
	at com.google.cloud.hadoop.services.repackaged.com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
	at com.google.cloud.hadoop.services.repackaged.com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57)
	at com.google.cloud.hadoop.services.repackaged.com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
======== End of Cloud Dataproc Agent Error ========

Did I create the cluster correctly? Are these errors at all revealing as to what might be going on?

@hzyi-google Any updates from the Dataproc team on this issue?

@droazen They are working on fixing what you were seeing in the previous comment since I last heard from them. I'll follow up with them and get back to you. Really appreciate your patience.

This is from the dataproc team:

The initialization action has been updated to force a Dataproc agent restart after installing the custom connector. I've just verified that job submission is operating correctly after upgrading the connector using the new version of the init action.

@hzyi-google
I tried creating a cluster with the initialization action:
gcloud dataproc clusters create louisb-test-cluster --initialization-actions gs://dataproc-initialization-actions/connectors/connectors.sh --metadata 'gcs-connector-version=1.8.1' --metadata 'bigquery-connector-version=0.12.1' --num-workers 4 --num-masters 1 --image-version 1.2

The error that @droazen saw is gone, but the 404 error has returned.
com.google.cloud.storage.StorageException: Error code 404 trying to get security access token from Compute Engine metadata for the default service account. This may be because the virtual machine instance does not have permission scopes specified.
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.translate(HttpStorageRpc.java:220)
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.get(HttpStorageRpc.java:415)
	at com.google.cloud.storage.StorageImpl$5.call(StorageImpl.java:198)
	at com.google.cloud.storage.StorageImpl$5.call(StorageImpl.java:195)
	at shaded.cloud_nio.com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:89)
	at com.google.cloud.RetryHelper.run(RetryHelper.java:74)
	at com.google.cloud.RetryHelper.runWithRetries(RetryHelper.java:51)
	at com.google.cloud.storage.StorageImpl.get(StorageImpl.java:195)
	at com.google.cloud.storage.contrib.nio.CloudStorageFileSystemProvider.checkAccess(CloudStorageFileSystemProvider.java:614)
	at java.nio.file.Files.exists(Files.java:2385)
	at htsjdk.samtools.util.IOUtil.assertFileIsReadable(IOUtil.java:429)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:206)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:162)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:118)
	at org.broadinstitute.hellbender.engine.ReadsDataSource.<init>(ReadsDataSource.java:87)
	at org.broadinstitute.hellbender.engine.spark.datasources.ReadsSparkSource.getHeader(ReadsSparkSource.java:214)
	at org.broadinstitute.hellbender.engine.spark.GATKSparkTool.initializeReads(GATKSparkTool.java:469)
	at org.broadinstitute.hellbender.engine.spark.GATKSparkTool.initializeToolInputs(GATKSparkTool.java:449)
	at org.broadinstitute.hellbender.engine.spark.GATKSparkTool.runPipeline(GATKSparkTool.java:439)
	at org.broadinstitute.hellbender.engine.spark.SparkCommandLineProgram.doWork(SparkCommandLineProgram.java:30)
	at org.broadinstitute.hellbender.cmdline.CommandLineProgram.runTool(CommandLineProgram.java:135)
	at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMainPostParseArgs(CommandLineProgram.java:180)
	at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:199)
	at org.broadinstitute.hellbender.Main.runCommandLineProgram(Main.java:160)
	at org.broadinstitute.hellbender.Main.mainEntry(Main.java:203)
	at org.broadinstitute.hellbender.Main.main(Main.java:289)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.spark.deploy.JavaMainApplication.start(SparkApplication.scala:52)
	at org.apache.spark.deploy.SparkSubmit$.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:879)
	at org.apache.spark.deploy.SparkSubmit$.doRunMain$1(SparkSubmit.scala:197)
	at org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:227)
	at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:136)
	at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
Caused by: java.io.IOException: Error code 404 trying to get security access token from Compute Engine metadata for the default service account. This may be because the virtual machine instance does not have permission scopes specified.
	at shaded.cloud_nio.com.google.auth.oauth2.ComputeEngineCredentials.refreshAccessToken(ComputeEngineCredentials.java:152)
	at shaded.cloud_nio.com.google.auth.oauth2.OAuth2Credentials.refresh(OAuth2Credentials.java:175)
	at shaded.cloud_nio.com.google.auth.oauth2.OAuth2Credentials.getRequestMetadata(OAuth2Credentials.java:161)
	at shaded.cloud_nio.com.google.auth.http.HttpCredentialsAdapter.initialize(HttpCredentialsAdapter.java:96)
	at com.google.cloud.http.HttpTransportOptions$1.initialize(HttpTransportOptions.java:161)
	at com.google.cloud.http.CensusHttpModule$CensusHttpRequestInitializer.initialize(CensusHttpModule.java:120)
	at shaded.cloud_nio.com.google.api.client.http.HttpRequestFactory.buildRequest(HttpRequestFactory.java:93)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.buildHttpRequest(AbstractGoogleClientRequest.java:300)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
	at shaded.cloud_nio.com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
	at com.google.cloud.storage.spi.v1.HttpStorageRpc.get(HttpStorageRpc.java:412)
	... 34 more

Ack.

@lbergelson may you provide up to date pom.xml and mvn dependency:tree output?
Also, you may try to create cluster with latest GCS connector version - 1.9.0

Looking into provided repro: https://github.com/jean-philippe-martin/nio-auth-repro

@medb @jean-philippe-martin Thank you both.

This is not a Dataproc specific issue, it is reproducible on vanilla GCE VM too.
Presumably issue is caused by bug in shading configuration in newer versions of the google-cloud-nio library.
Issue is not reproducible locally, because locally it uses client authentication, not a service account.
Fix is here: https://github.com/jean-philippe-martin/nio-auth-repro/pull/1

@medb How do you reproduce on a vanilla GCE vm?  We have not had any trouble running jobs on GCE with new versions of the library other than on dataproc.  It would be useful if we could trigger it outside of dataproc to debug it more easily.

I was using this repro app to run it locally, on GCE VM and Dataproc cluster.
Locally (my workstation) it always work, but this is just because it does not use service account for authentication, on GCE VM and Dataproc it uses it.

@medb you're right, I was able to reproduce on a vanilla GCP VM. I started with an Ubuntu 16.04 image with "Allow full access to all Cloud APIs" enabled, then installed openJDK on it and ran the jar - it failed as before, complaining about potential misconfigured scopes.
Just to check, I then typed "gcloud auth application-default login", and ran it again. This time, it worked beautifully.
So it looks like there's something about the combination of default service account and GCE that causes issues.

I had an interesting result playing with the way the shading is done for the NIO jar.
The current NIO jar uses a <pattern>com</pattern> section in the maven-shade-plugin section. I changed it to still shade exactly the same things, but via two move specific patterns: <pattern>com.google and <pattern>com.fasterxml.
When used in my repro app, the resulting jar results in the test passing - both in a GCE VM and when used via Dataproc.
This is very promising. The next step is to try this with GATK itself and see if that solves the problem.

Great catch, this should be it! Usually com/org/io patterns are too aggressive for shading.

@jean-philippe-martin That's great news! If you open a PR here, we'd be happy to try out the patch with GATK on our end.

@droazen @medb I put up some code at https://github.com/GoogleCloudPlatform/google-cloud-java/pull/3568 with this change, the repro works (the getBucket method passes).

@jean-philippe-martin I tested your branch using GATK, and it appears to completely resolve this issue!

@droazen what wonderful news! That's great!

I was able to identify the root cause, it's https://issues.apache.org/jira/browse/MSHADE-156

I've confirmed that this issue is resolved with the latest release (0.59.0), so this can finally be closed! Thanks to everyone for their assistance over the past year!

This long nightmare is over, but I forgot to close the issue.   Closing it.  Thank you everyone.


Allow multiple files (platforms) when submitting unlisted addons (bug 1173125)

Fixes bug 1173125
This PR is based on PR #578, only the last commit is relevant to this change.

@kmaglione can you confirm that this is the bug you're talking about?

Thanks for the review @kmaglione, very helpful!
I've updated the code, and added/improved the tests, please let me know if it's good now.


[gdal] x64-linux BUILD_FAILED

Trying to install gdal on a fresh ubuntu 18.04 x64 using a fork of latest vcpkg master fails with:
Starting package 5/18: gdal:x64-linux
Building package gdal[core]:x64-linux...
-- Using cached /home/wii/Pro/vcpkg/downloads/gdal241.zip
-- Extracting source /home/wii/Pro/vcpkg/downloads/gdal241.zip
-- Applying patch /home/wii/Pro/vcpkg/ports/gdal/0001-Fix-debug-crt-flags.patch
-- Applying patch /home/wii/Pro/vcpkg/ports/gdal/0002-Fix-static-build.patch
-- Extracting source /home/wii/Pro/vcpkg/downloads/gdal241.zip
-- Applying patch /home/wii/Pro/vcpkg/ports/gdal/0001-Fix-debug-crt-flags.patch
-- Applying patch /home/wii/Pro/vcpkg/ports/gdal/0002-Fix-static-build.patch
-- Building x64-linux-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:56 (message):
    Command failed: NMAKE-NOTFOUND;-f;makefile.vc;GDAL_HOME=/home/wii/Pro/vcpkg/packages/gdal_x64-linux;DATADIR=/home/wii/Pro/vcpkg/packages/gdal_x64-linux/share/gdal;HTMLDIR=/home/wii/Pro/vcpkg/packages/gdal_x64-linux/share/gdal/html;GEOS_DIR=/home/wii/Pro/vcpkg/installed/x64-linux/include;GEOS_CFLAGS=-I/home/wii/Pro/vcpkg/installed/x64-linux/include -DHAVE_GEOS;PROJ_INCLUDE=-I/home/wii/Pro/vcpkg/installed/x64-linux/include;EXPAT_DIR=/home/wii/Pro/vcpkg/installed/x64-linux/include;EXPAT_INCLUDE=-I/home/wii/Pro/vcpkg/installed/x64-linux/include;CURL_INC=-I/home/wii/Pro/vcpkg/installed/x64-linux/include;SQLITE_INC=-I/home/wii/Pro/vcpkg/installed/x64-linux/include;PG_INC_DIR=/home/wii/Pro/vcpkg/installed/x64-linux/include;OPENJPEG_ENABLED=YES;OPENJPEG_CFLAGS=-I/home/wii/Pro/vcpkg/installed/x64-linux/include;OPENJPEG_VERSION=20100;WEBP_ENABLED=YES;WEBP_CFLAGS=-I/home/wii/Pro/vcpkg/installed/x64-linux/include;LIBXML2_INC=-I/home/wii/Pro/vcpkg/installed/x64-linux/include;PNG_EXTERNAL_LIB=1;PNGDIR=/home/wii/Pro/vcpkg/installed/x64-linux/include;MSVC_VER=1900;WIN64=YES;PROJ_FLAGS=-DPROJ_STATIC;CURL_CFLAGS=-DCURL_STATICLIB;CXX_CRT_FLAGS=/MD;PROJ_LIBRARY=/home/wii/Pro/vcpkg/installed/x64-linux/lib/proj.lib;PNG_LIB=/home/wii/Pro/vcpkg/installed/x64-linux/lib/libpng16.lib;GEOS_LIB=/home/wii/Pro/vcpkg/installed/x64-linux/lib/libgeos.lib;EXPAT_LIB=/home/wii/Pro/vcpkg/installed/x64-linux/lib/expat.lib;CURL_LIB=/home/wii/Pro/vcpkg/installed/x64-linux/lib/libcurl.lib wsock32.lib wldap32.lib winmm.lib;SQLITE_LIB=/home/wii/Pro/vcpkg/installed/x64-linux/lib/sqlite3.lib;OPENJPEG_LIB=/home/wii/Pro/vcpkg/installed/x64-linux/lib/openjp2.lib;WEBP_LIBS=/home/wii/Pro/vcpkg/installed/x64-linux/lib/webp.lib;LIBXML2_LIB=/home/wii/Pro/vcpkg/installed/x64-linux/lib/libxml2.lib
    Working Directory: /home/wii/Pro/vcpkg/buildtrees/gdal/src-x64-linux-release/gdal-2.4.1
    Error code: No such file or directory
    See logs for more information:

Call Stack (most recent call first):
  ports/gdal/portfile.cmake:221 (vcpkg_execute_required_process)
  scripts/ports.cmake:71 (include)

Error: Building package gdal:x64-linux failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: gdal:x64-linux
  Vcpkg version: 2018.11.23-unknownhash

Additionally, attach any relevant sections from the log files above.

No other log generated, so I do not know what file/folder does not find.

ubuntu 18.04 x64
Command failed: NMAKE -NOTFOUND
PORT under Windows

On windows it works, I need it under linux

My PR has been merged. Close this issue.


enumValues with exported type break type safety

Describe the bug
When specifying enumValues and pointing to an exported type directly, the exported type could not match the enum at all.
This means the schema isn't enforced on the types imported and it breaks type safety.
To Reproduce
Steps to reproduce the behavior:

My GraphQL schema:

enum Foobar {
  FOO
  BAR
}

type Something {
  someArg: String!
  someFoobar: Foobar!
}

input SomeInput {
  foobar: Foobar!
}

type Query {
  show(input: SomeInput!): String
}

My codegen.yml config file:

schema: ./**/*.graphql
generates:
  ./schema-types.ts:
    plugins:
      - typescript
    config:
      namingConvention:
        enumValues: keep
      typesPrefix: "Graphql"
      enumPrefix: false
      nonOptionalTypename: false
      avoidOptionals: false
      skipTypename: true
      scalars:
        Date: "string"
        Cursor: "string"
        JSON: "{ [key: string]: any }"
      enumValues:
        Foobar: ./index#Foobar

Sandbox link

-> https://codesandbox.io/s/exciting-haibt-xpoln?file=/codegen.yml
Expected behavior
As you can see in the generated types, Foobar is properly used from the exported existing type, itself imported from index#Foobar.
Because we delegated the enum to a re-export of a pre-defined enum, the schema is no longer the source of truth here, which means that I can have an enum that partially (or not at all) implements an enum defined in the schema.
Could the generator make an extra check on this to see if all schema-defined keys are present in the code-defined enum?
That would give a better level of type safety.
Environment:
See Sandbox: https://codesandbox.io/s/exciting-haibt-xpoln?file=/index.ts

@dotansimha, @charlypoly Seems like this observation might be useful. I also kinda facing type safety issues with generated enums signature, and what I found, and can't answer on, is why this (from generated .ts file)
export type EnumResolverSignature<T, AllowedValues = any> = { [key in keyof T]?: AllowedValues };

has keys of a resolver defined as optional? I manually removed optional modifier, and TS started to react on the case similar to @Shahor case, as well as it started to react to cases like enums names miss match.
Idk what else might happen if we would just remove optional modifier, but it seems like it's a root cause. Why it was added in the first place?? I took a look at original PR when enumsValues where implemented and found nothing which could've helped me to answer that.
I'd create a PR if we'd come to agreement that this is a relatively safe change.


feat(anta.tests): Added testcases for AVT feature

Description
Added the test cases for AVT features.
Fixes #615
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my code
[ ] I have run pre-commit for code linting and typing (pre-commit run)
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes (tox -e testenv)

@MaheshGSLAB can you move the faiing test with ping avt in another PR and we will merge the 3 others?


Deterministic key pair from a seed

Hi everybody,
I know that in order to have strong keys, we need to have two random numbers but on the other hand, it is difficult to recover a lost key. Is there a possibility to allow generation of keys based on a deterministic seed as it is done in BIP-32/39 to allow easy recovery of the keys?
Thank you.

I was able to generate deterministic RSA private key using RsaPrivateKey::from_components.
So, I am closing this issue.

@elielnfinic FYI, if this is helpful:
RsaPrivateKey::new accepts an RngCore + CryptoRng argument.
You can use e.g. ChaCha8Rng for this, which produces a random keystream from a 256-bit seed.

Thanks @tarcieri, I was able to generate deterministic pair with ChaCha8Rng.
I am using bip32 library to generate seed from mnemonic but it generates  a [u8; 64] though ChaCha8Rng accepts [u8; 32]. Can you suggest any library to generate that outputs [u8; 32] from a mnemonic phrase?

I have been able to overcome this issue by using ChaCha8Rng::seed_from_u64 by hashing the mnemonic to a u64 integer.

A u64 has insufficient entropy to be secure. You really need to initialize it with 256-bits/32-bytes entropy.
BIP32 derivation should produce two values: a 32-byte derived secret, and a 32-byte “chain code”. You can use the 32-byte secret as the key, ignoring the “chain code”

Sure, thank you @tarcieri.
I really appreciate.


Change uN types to natN

I think it makes more sense for the Azle syntax to match Candid more than to match Rust, thus we should change the u128, u64, etc to nat, nat64, etc.
Also get rid of the i128 and u128 types and just use nat and int

Done!


Update task to use var defined in group_vars

Overview
When running scripts/setup -–vagrant, provisioning would eventually fail at the Ansible task Set IOW_BOUNDARY_TOOL_SETTINGS_BUCKET with the below error output:
TASK [iow-boundary-tool.environment : Set IOW_BOUNDARY_TOOL_SETTINGS_BUCKET] ***
fatal: [default]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'iow' is undefined\n\nThe error appears to be in '/vagrant/deployment/ansible/roles/iow-boundary-tool.environment/tasks/main.yml': line 8, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Set IOW_BOUNDARY_TOOL_SETTINGS_BUCKET\n  ^ here\n"}

RUNNING HANDLER [azavea.docker : Restart Docker] *******************************

PLAY RECAP *********************************************************************
default                    : ok=14   changed=11   unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

The ansible task was unable to find the right variable within the play because we were trying to evaluate an environment variable that wasn't set in group_vars. This renames the variable defined in the group_vars file to the appropriate project name and adjusts the task to use the renamed variable to set IOW_BOUNDARY_TOOL_SETTINGS_BUCKET instead.
Demo
TASK [iow-boundary-tool.environment : Set AWS_PROFILE] *************************
ok: [default]

TASK [iow-boundary-tool.environment : Set IOW_BOUNDARY_TOOL_SETTINGS_BUCKET] ***
ok: [default]

Testing Instructions

scripts/setup –-vagrant
Confirm IOW_BOUNDARY_TOOL_SETTINGS_BUCKET set to the correct value in the Ansible task logs
Confirm vagrant vm provisions successfully

Checklist

[x] fixup! commits have been squashed
[x] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines
[x] README.md updated if necessary to reflect the changes
[ ] CI passes after rebase

This provisioned correctly. Let's also uncomment and change this line to 8181, needed for Django access via Vagrant:
https://github.com/azavea/iow-boundary-tool/blob/3e0f1c744d0d05aed96c3e90ccd62313fb66323b/Vagrantfile#L27


Update message links to non-existent release

Both the 1.6 and 1.7 releases have had bad links from inside the client:
https://github.com/Franiac/TwitchLeecher/releases/tag/v1.7
This link is dead, the correct link goes to 1.7.0:
https://github.com/Franiac/TwitchLeecher/releases/tag/v1.7.0

This bug is fixed in 1.7.0 (see release notes)
How can you even tell 1.7.0 has it when you never saw the update dialog?

Whoops, my bad! I saw the "1.7" link dead (which was obv a problem with 1.5 and 1.6), and assumed that it had to do with the new update, as opposed to the previous one.


Question: Handling of optional properties.

Hey, I love your library !
I read your article and I've been searching for such tool for years!
I have a question though.
Do you have any advice on how to handle optional properties ?
Here is example, lets say I have an interface representing task:
interface Task {
    name: string; // required
    estimate?: number // optional
}

and I'm creating a Type Guard:
const isTask = createTypeGuard<Task>((task) => {
  if (typeof task === "object" && task !== null && hasProperties(task, "name")) {
    const { name } = task;

    if (typeof name === "string") {
      return { name };
    }
  }
  return null;
});

This seems to works (TypeScript does not complain), but I can pass wrong type of estimate like and isTask will be wrong too :
const myTask = {name: "Example task", estimate: true}; // note that estimate is number not boolean
isTask(myTask) // true

I've modified my Type Guard to include the optional parameter estimate like so:
const isTask = createTypeGuard<Task>((task) => {
  if (typeof task === "object" && task !== null && hasProperties(task, "name", "estimate")) { // 1. added it here
    const { name } = task;

    if (typeof name === "string" && (typeof estimate === "undefined" || typeof estimate === "string") { // 2. checked type or undefined
      return { name, estimate };
    }
  }
  return null;
});

This works great, and handles the optional parameters perfectly. The previous example now returns false.
const myTask = {name: "Example task", estimate: true}; // note that estimate is number not boolean
isTask(myTask) // false

The only downside is that I still need to manually manage the optional properties here:
hasProperties(task, "name", "estimate")

If I add new optional parameter to Task - typescript will not report any issues.
Do you have any advice and if it possible at all to on how to handle optional properties more automatically ?
Best regards,
Alex

I just wrote the question and found a really elegant way to make it work.
instead of writing
const isTask = createTypeGuard<Task>(...)

I did
const isTask = createTypeGuard<Required<Task>>(...)

This makes every property on the Task required and TypeScript demands every property to be checked regardless if it was original required or optional.
Actually I can't see any issue this Required<...> type to become even part of the library. That way the parser will always force you the check every single property regardless if it is optional or required.


Architecture redesign: Child Modules and LazyLoading

Now the application includes one root Module (AppModule) and different child Modules (one per scope).
This allows us to use LazyLoading approach: loading modules under demand, when required,  improving scalability and loading size/times.

Hi Roberto,
I´m not sure if I followed your steps correctly, but the changes should properly work (at least at my environment :))
What is your opinion about the new approach? I hope you find it interesting.
Regards,
Andrés.

Hi Andrés, thanks a lot for this pr. Yes, lazy loading is important in a real scenario. I'm off-line these days. I'll see the commit as soon as possible. Greetings

Hi Andrés, finally I did the merge of your pr. I had to remove some unnecessary files and uniformize the style. I fixed auth guard and added preloading strategy for all modules: https://github.com/robisim74/AngularSPAWebAPI/pull/18/commits/3640fd5fe5ebbf91fdfb51ed3605c3733cbba48c
Thank you again a lot for your work!
Greetings,
Roberto

Hi Roberto,
You are welcome! :)


Fix repo GPG key import issues

The gpg keys for the google repos, even when the gpg check is disabled, are failing to import when building on F38, breaking the set up of the build root:
error: Certificate FEEA9169307EA071:
  The certificate is expired: The primary key is not live
error: /tmp/gpgkey.zqjj6b_b: key 1 import failed.
error: Certificate 8B57C5C2836F4BEB:
  The certificate is expired: The primary key is not live

Updating the repository and adding the key from the current repository doesn't fix the issue.
I updated the Google repositories to the most recent snapshots and dropped the key to unbreak test builds until we can find the issue.
Originally posted by @achilleas-k in https://github.com/osbuild/images/issues/59#issuecomment-1655483406

Same for jbeap7 repos.


PR to support modular interface?

Hello, and thanks for this neat and useful toolchain.  I'm trying to do a better job of managing my OpenWRT-based router and APs, and as a confirmed Nixaholic this repository is just what I needed.
Would you be interested in a PR introducing a modular interface to the OpenWRT image builder code?  I have a (very) rough cut at such an interface up on SourceHut here.
The high-level view:
{
  openwrtImages.default = self.lib.openwrtImage {
    modules = [
      {
        image = {
          profileName = "avm_fritz7412";
          packages.include = ["tcpdump"];
          packages.exclude = ["ppp"];
          disabledServices = ["dnsmasq"];
          snippets."etc/uci-defaults/99-custom".text = ''
            uci -q batch << EOI
            set<EMAIL_ADDRESS>            commit
            EOI
          '';
        };
      }
    ];
  };
}

If specified as a flake output, the image and associated assets could then be built with nix build '.#openwrtImages.default.config.system.build.image' .  I plan to add a wrapper command for this that would permit doing, say, nix-openwrt-imagebuild '.#default'.
Any interest in integrating something like this in your project?
Thank you!

In general, great idea! I already use the NixOS module system for networking configuration.
However, this piece of code already has a few ways of calling it. I prefer the managability and flexibility of putting lib.evalModules in my own code, passing the nix-openwrt-imagebuilder parameters together in one place. Are there use-cases where doing so would be inconvenient?
To me it starts to make sense if we start defining all the OpenWRT options as sensible NixOS module options. @ehmry launched a fork into this direction starting in #9. Although it would be nice to have, I am not sure I am ready to maintain and update such a bulk of declarations. Can it be automated just like I've done with the download hashes?

I'm not working with OpenWRT anymore so I'm not maintain my module fork. As I recall @mic92 has  similar configuration work that is relevant.

https://github.com/Mic92/dotfiles/blob/main/openwrt/example.nix

There is also https://git.eno.space/dewclaw.git/tree/ now.

Hey, @tomeon! I noticed that your sourcehut repository is active and that you have implemented a very comprehensive module system, including the flake-parts module ❤. Are you still interested in creating a PR to port it to this repository? 👀
I believe everyone would benefit from a more modular system that allows for atomic changes, better type-safety, and auto-generated documentation similar to NixOS modules.

Regarding @astro's comment:

Although it would be nice to have, I am not sure I am ready to maintain and update such a bulk of declarations.

I think @tomeon's approach to modules is simpler and easier to maintain than what was proposed in https://github.com/astro/nix-openwrt-imagebuilder/pull/9. While it would be great to have many individual services wrapped into Nix expressions like NixOS service modules, I agree that it would be hard to maintain.
In my opinion, wrapping UCI expressions into NIX and exposing packages, disabledServices, and files makes more sense, as it aligns more closely with what is already implemented in this repository and with ImageBuilder's interface.

@astro  -- apologies for taking so long to reply here.  Maybe it is superfluous now that #48 appears to have traction, but I'd like to put my thoughts down anyway.
I agree with @pedorich-n's remark that

everyone would benefit from a more modular system that allows for atomic changes, better type-safety, and auto-generated documentation similar to NixOS modules.

However, since it's likely everyone here is already convinced of the benefits of modular systems in general and the NixOS module system in particular, let's talk about the benefits specific to my implementation of a modular interface to this project.

I prefer the managability and flexibility of putting lib.evalModules in my own code, passing the nix-openwrt-imagebuilder parameters together in one place. Are there use-cases where doing so would be inconvenient?

It's not inconvenient for me personally, or (as far as I can guess) for any single person.  However, there is the potential for the collective inconvenience of repeated wheel-reinvention.  One of my goals in implementing a modular interface is to expose interfaces at various levels of abstraction, reducing the likelihood of needing to re-implement low-level plumbing while still making it possible to futz with the plumbing when necessary.
A case in point here is the layering of options that eventually get composed into the derivation that's passed as the files argument to the image builder function.  From highest- to lowest-level:

The (semi-)declarative UCI defaults options, which compose into
UCI instructions, which compose into
Text snippets representing the bodies of scripts to be installed in /etc/uci-defaults, which compose into
Derivations built with pkgs.writeTextDir, which compose into
A final, single derivation passed as the files argument to the image builder function.

At each of these levels, barring the lowest,[^direct-files-control] it is possible to take the reins directly:

The (semi-)declarative UCI defaults options are where I'd hope the bulk of the configuration will go; they are at least intended for that purpose.
UCI instructions can be specified explicitly if (for instance) the user needs fine-grained control over instruction sequencing.
Text snippets can be defined directly if (for instance) the user needs to do something other than run uci batch in an /etc/uci-defaults script.
Derivations can be added directly to the list composed into the files argument.

I believe this represents a reasonably thorough hierarchy that balances power and convenience.
Regarding

To me it starts to make sense if we start defining all the OpenWRT options as sensible NixOS module options. [...] Although it would be nice to have, I am not sure I am ready to maintain and update such a bulk of declarations. Can it be automated just like I've done with the download hashes?

I again concur with @pedorich-n's remarks.
I do not think that it would be straightforward or even possible to implement a comprehensive modeling of "all the OpenWRT options".  For one, I don't think there is any canonical representation of all available options, other than their implementation in the OpenWRT codebase.  I certainly have not found any API that can be queried to get all of these options and their default values for a given OpenWRT-supported device.
Instead, I've focused on building a more-or-less comprehensive interface to the UCI defaults system.[^uci-defaults]  This way, consumers of the modular interface can declare and define just the settings that they need for the target device.  It might not be as polished an experience as working with NixOS itself -- however, if the modeling of the UCI defaults system is reasonably comprehensive, then it could be used as the basis for implementing even-higher-level interfaces if and when it looks like it would be useful to do so.
[^direct-files-control]: This is probably a mistake; users should be able to directly control the contents of the files argument.  I'll update the module accordingly.
[^uci-defaults]: I am not entirely satisfied with the implementation, particularly the interface to "unnamed" options.  I've represented sparse lists as Nix attribute sets whose keys are list indices, and provided library functions to help with defining such sparse lists, but the experience is clumsier than I'd like.

I like the module system, and there seem to be even more gems in your fork. I'm happy to merge when it's ready.
Of course I'd appreciate small separate PRs but only if it's feasible.
I would really like to see support added for the current lib API so we could offer at least Flake users a seamless upgrade path.


borrow and export %>% from magrittr

Need to have this available externally to package users (similar to how dplyr exposes it)

I can take a shot at this


about

Thank you for your excellent work. I would like to try the results on our gas dataset. Do you have any plans to publish checkpoints？

Sure. we will do so in the future.


Added pre-commit to catch markdownlint errors earlier

Hi @TessFerrandez , can you please review this. This PR aims to close issue https://github.com/microsoft/code-with-engineering-playbook/issues/465


Plan Sender retro for Flu pilot with SR and RS

Background and context
We plan to conduct a focus group with SimpleReport to gather their feedback on the pilot as a sender.
Open Questions (as needed)

What tool do we want to use for this? Mural, EasyRetro...
What estimated date should we target? Based pilot progress and eng capacity
Who should be invited? SR eng, PMs, RS eng, PMs
What topics are most important to focus on?

Acceptance Criteria

[ ] Tool selected and set up for session

[ ] Facilitation guide created for session

[ ] Meeting date selected

[ ] Calendar invite sent

@jsutantio lets merge and keep this one! Thanks for the catch


Implement CopyToAsync on FrameRequestStream

Resolves #1096

Nope, far from actually 😄 . Needs to expose the buffers directly in the memory pool.

And I thought this was messy :laughing:
Will need to work with the fun logic of message body and its variants https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNetCore.Server.Kestrel/Internal/Http/MessageBody.cs#L24-L37

Yahp 😄 shouldn;t be too bad though


EaselJSRenderers needs update?

I was looking at this: https://github.com/CreateJS/EaselJSRenderers and noticed that it doesn't work with the current build of EaselJS.
Can this be updated?
PS - I'm curious if there will be any performance boost with 'Renderer2DMtx'
PSS - Why use "next" as a version? "next" from what year? Please just keep versions a number ;)

The Renderers are out of date, and will not be updated, as we are deprecating SpriteStage/SpriteContainer in favour of the new (and way better) StageGL approach, which is currently available in the StageGL-beta branch in GitHub.
As for the naming, the NEXT name refers to "what is currently in GitHub" between official releases (ie, the next release). This provides a minified version with the latest features until they become official and are put on the CreateJS CDN.
I am closing this for now.

The Renderers are out of date, and will not be updated, as we are deprecating SpriteStage/SpriteContainer in favour of the new (and way better) StageGL approach, which is currently available in the StageGL-beta branch in GitHub.
As for the naming, the NEXT name refers to "what is currently in GitHub" between official releases (ie, the next release). This provides a minified version with the latest features until they become official and are put on the CreateJS CDN.
I am closing this for now.


Add more information and links about contributing

Here are some great models for how other projects help folks contribute, especially first-time contributors.  We should adapt these for this project and add them to the contributing section of the README.

Write a contribution guide documenting the design decisions · Issue #6335 · facebook/react
How to Contribute to an Open Source Project on GitHub

Working on this tonight, following a GitHub standard flow, described here.  The root-level file named CONTRIBUTING.md, can/should be linked to from appropriate places in the more general project README file.
This is especially handy because when a repo contains a file named CONTRIBUTING.md then when people add issues GitHub will automatically trigger display of a notice along these lines:

According to GitHub:

In the new file, add contribution guidelines. These could include:

Steps for creating good issues or pull requests.
Links to external documentation, mailing lists, or a code of conduct.
Community and behavioral expectations.

Here goes...

Very cool, did not know that bit about the flash notice @dazzaji! A nice bit of sugar to help the community contribution process flow smoother! :rainbow:

Hey look, here it is!

Looking good!  So, is this ready to close or are there more things to do?

@dazzaji This is an awesome improvement, thank you!  It'd be great to add the egghead links to how to do the GitHub flow (since walking through this has come up several times over the last few weeks at Code for Boston).
For the sake of good issue hygeine, let's cut the vaguer bits about context and high-level design decisions for now.  But for the thought trail, things that have come up a few times already are why are we defining styles directly in React  (eg., https://speakerdeck.com/vjeux/react-css-in-js as background), or how to make me JS modules with each file stuffed into window.shared at the moment.

I'm not exactly sure what you are suggesting be cut. Can you go ahead and make this change and then close this issue? Thanks.

@dazzaji ahh sorry for being confusing.  I lumped a few things into this issue initially, just to capture it and I can see why that is totally lost without mind reading skills. :)  I'm suggesting part of my issue be cut, not your awesome contribution
I split the remaining bit out to https://github.com/studentinsights/studentinsights/issues/251, and clarified that that bit is about documentation high-level design decisions, since those have come up a few times at Code for Boston and it's good to externalize.
I also added a commit here https://github.com/studentinsights/studentinsights/pull/248/commits/89971854bd8fd14588b8358d5485681d09fbdbc7 to the a more walkthrough-style tutorial on the GitHub workflow so we can :closed_book: this sucker out.  Thanks again @dazzaji and for speaking up about how I could help clarify. :)


Conversion from str literals to String

Description
Add a convenience method to convert string literals to the tentative dynamically sized String like so:
String::from_ascii_str("Lorem Ipsum")

Checklist

[x] I have linked to any relevant issues.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book).
[x] I have added tests that prove my fix is effective or that my feature works.
[x] I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
[x] I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
[x] I have requested a review from the relevant team or maintainers.

Can't do that without a From trait that is properly unidirectional.
Which in turn requires #4702


Unable to schedule from a specific time and following a specific calendar

The library supports scheduling until a certain time but not from time. Consequently, it is difficult to implement logic such as every hour on Monday-Friday from 11:30 to 12:30.
We created a custom function that generates a list of options, in this case

every().monday.at("11:30")
every().monday.at("12:30")
every().tuesday.at("12:30")
..,
every().friday.at("12:30")

This implies 15 calls, as opposed to only 5 calls per each day, or just 1 call per calendar that sets Monday to Friday eligible.
With a more frequent schedule, this becomes even more prohibitive. In such a case, we just run the job at every().minute and exit early when outside of schedule from job function, i.e. manage schedule externally.
Any enhancements planned? Any idea how to enhance internally the library?

every().monday.from('11:30').to('12:30')
every().minute.on(calendar).from('11:30').to('12:30')

@SijmenHuizenga could you please assess feasibility and complexity arising from scheduling

from specific time (e.g. every minute from 11:00 to 11:30),
on specific week days (e.g. monday to friday),
following specific calendar (e.g. list of datetime objects)?

I agree with dbader sentiment to keep this library lightweight and not turn it into next large unmaintainable project (#219). However, the above would considerably increase expresiveness.

@SijmenHuizenga could you please confirm if above requirements significantly increase complexity / decrease maintainability?


change: [M3-8159] - Modify limited availability banner display logic

Description 📝
This PR modifies the display logic of the limited availability banner in the Selection Plan. This is the result of product wanted to limit the display of the banner, especially as it relates to the 512Gb plan since the banner would always display for any class with a 512 plan.
The solution was to only display the banner if more than half of the plans are disabled. Since that logic already existed for the disabled tooltip, I leveraged this util to apply it to the notice.
As a result, the logic is as follow:

If more than half plans are disabled, show the limited availability banner and hide the limited availability tooltip
If less than half plans are disabled, hide the limited availability banner and show the limited availability tooltip

Additionally, it was decided to include the "learn more" link in the Class description copy and remove it from the banner so it is always available for the user now that the banner won't display often.
Changes  🔄

Update limited availability banner display logic
Remove the "Learn More" copy from the limited availability banner
Update the Class copy to feature the "Learn More" copy
Update selection plan e2e suite

Target release date 🗓
6/10/2024
Preview 📷

Before
After

How to test 🧪
Verification steps

Confirm updated display and no regression of selection plans (with different regions) in

Linode Create flows
Kubernetes Create flow
Database create flow

As an Author I have considered 🤔
Check all that apply

[ ] 👀 Doing a self review
[ ] ❔ Our contribution guidelines
[ ] 🤏 Splitting feature into small PRs
[x] ➕ Adding a changeset
[x] 🧪 Providing/Improving test coverage
[ ] 🔐 Removing all sensitive information from the code and PR description
[ ] 🚩 Using a feature flag to protect the release
[x] 👣 Providing comprehensive reproduction steps
[x] 📑 Providing or updating our documentation
[ ] 🕛 Scheduling a pair reviewing session
[ ] 📱 Providing mobile support
[ ] ♿  Providing accessibility support

thanks @mjac0bs - bare metal plans are kind of a special case (and you need an account flag for them to even show up). This is prolly a bit out of scope but i removed the display of the limited availability banner for them anyway since they handle their own. Good catch!


PWM output for GPIO

New readme looks good. It seems to be accurate to the code we implemented and is easy to understand for an outside user.


Using "Enabling debugging for embedded razor views" doesn't works

When I used the technique described in "Enabling debugging for embedded razor views".
If I put a breakpoint on the host constructor when a embedded Razor page is called, GetResourceFromVirtualPath() does return me a resource but resource.Filename is always null.

Hmm, that doesn't sound right...
Does the VPP actually work? Can you debug the Razor views?

The VPP works fine. But it seems all my embedded resources have no filenames.
If I put a breakpoint on the MyCustomRazorHost constructor and look at System.Web.Hosting.HostingEnvironment.VirtualPathProvider and I can see all my resources but they all have null filenames.
So PhysicalPath is always set to null for embedded resources and therefore the debugging of embedded Razor views doesn't seem to work in my case.

Are you a. trying to debug embedded views in a project in the same solution (so the source files are available b. trying to debug embedded views in an assembly where the source files aren't present on disk?
I think a. works (or worked, I haven't done this recently) and b. is unknown territory. Maybe the files should be extracted into a temp folder and that path used for FileName...

Hi there,
I am also having this problem - was there any further progress on this from the above? Happy enough to investigate this if this is a known issue.

Hi,
On my side I had to drop VPP altogether since they don't work with pre-compiled Razor views so I haven't dug further into the question.

Hi,
I've actually figured it out and it was an issue on my end - it will only return the filename if you populate the ProjectSourcePath parameter when registering the assembly with the Vpp class.
So adding in the custom factory in the steps provided here is now working for me.
However, there is an issue - using a custom razor factory appears to completely break intellisense in razor views in the MVC project.


When using plugin with React, peer dependencies related with Vue maybe not needed?

Hi, I'm using this awesome plugin for a while in my React project. That's great!
When deploying to vercel.com, the missing peerDependencies (vue & @vue/compiler-sfc) will cause build errors. But I'm actually not using Vue stack at all. 😂 Now I add them to my devDenpendencies and everything works fine.
So I think we should cancel these two peer dependencies in package.json, or after the experimental?

Try new version.

If someone have same issue on new version try deleteing node_modules and re-installing all dependencies, this solved for me.


Remove icons from menu/navigation

Tools
No response
Summary
In professionally made, high-quality websites you rarely run into icons in navigation menu. In low-quality websites and viruspages you on the other hand usually run into icons/emojis in menus. Avoid this, because this affects the user experience and the professional feel of the page.

Done


EscapeScope must chain off a parent Scope

For safety, we need to guarantee that an escaping handle will escape into a stack that has a live handle scope. To enforce this, we can simply make the run method a member method of Scope instead of a static:
scope.run(|innerScope| {
    ...
    innerScope.escape(handle)
})

Fixed in 3c596a00c424dc00f71364044f751bf7da24db26