tls-cipher schemes for control channel negotiation request and certificate read issue

Greetings all,
Congratulations and thanks for all this work you have done so far and the quest to implement post quantum algorithms into current cryptography protocols.
First of all I have to state that I have pretty basic knowledge of programming languages, but I can handle various operating systems. Lately I had the interest to start learning about cryptography and started encrypting my connection, playing around with the various available classic protocols etc.
I have successfully installed your software in both *nix based and microsoft platforms of mine, at least up to the openssl-integrated-with-liboqs stage, but still I am not sure I have understood how I should form the tls-cipher and/or tls-ciphersuites (for the openssl 1.1.1d version I use) directive to handle the oqskex. Also the openssl certificates I issue with the openssl commands (openssl seems to have been integrated correctly since I can use it for -at least- most of the pq algorithms) seem not readable from my openvpn software on neither side. (It provides various certificate related errors such as the "unsupported certificate purpose" / "certificate verify failed" / extended key usage errors etc.)
I reached as far as I could alone, but I think I will need your help to go further. I use Debian Buster and Windows 10 Pro Edition.
Any help and recommendation will be appreciated. Keep up the good work.
Best regards,
Alex

Hi Alex,
Thanks for your interest!
The current release of PQCrypto-VPN has only been tested against the OQS fork of OpenSSL 1.0.2. In fact there is a particular commit our build scripts sync to that we tested with. We have not tested against the 1.1 fork and so don't know if it will work. That being said, for TLS 1.2 on the control connection, tls-cipher is the OpenVPN configuration directive we used to select the relevant PQ ciphersuites, and guarantee that non-PQ ciphersuites would not be selected. For example, this is the precise directive I use in an internal deployment I have:
tls-cipher OQSKEX-SIDH-MSR-ECDHE-RSA-AES256-GCM-SHA384:OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-RSA-AES256-GCM-SHA384
This prefers the hybridized-with-ECDHE versions of SIDH first and then Frodo, using RSA certificates for authentication.
The OpenSSL 1.1 branch supports TLS 1.3, and because of the way ciphersuites changed in TLS 1.3, we have run into some problems. Key exchange and authentication algorithms are no longer specified as part of the ciphersuite, and so tls-cipher will no longer work. If you have our code building against the OpenSSL 1.1 branch, you may be running into OpenSSL trying to negotiate a TLS 1.3 session which will not end up using a PQ key exchange algorithm. You may be able to force it to use TLS 1.2 by specifying the --tls-version-max 1.2 configuration directive to OpenVPN and then use tls-cipher like above, but I can't predict if this will work since the 1.1 fork is a significant diversion from the 1.0.2 fork we originally built on. You may need to dig into the source code for the version of OQS-OpenSSL you're building against to look up the TLS 1.2 ciphersuite names that use PQ key exchange algorithms. For best results, I suggest building with the 1.0.2 fork from the commit referenced in our build scripts. If you get a connection going, you will need to closely review the log output from OpenVPN to make sure you are actually using a post-quantum key exchange, and not being defaulted back to a classical algorithm.
We currently have work underway to update PQCrypto-VPN both to the latest version of OpenVPN, and also to make it compatible with OpenSSL 1.1 and TLS 1.3. Our next release will support both.
Now about your certificate question: The errors you describe sound like the wrong Extended Key Usage OIDs being set in the certificates. If you look in our instructions for setting up a Picnic PKI, under the "Create a server certificate" section there is an example extensions file which you can use to tell OpenSSL which EKUs to apply to each certificate. Server certificates have to have the serverAuth EKU and client certificates have to have the clientAuth EKU. If these aren't correct, you'll see certificate validation errors like the ones you've noted. You can feed a certificate to the OpenSSL command line utility with openssl -in cert.cer -noout -text where cert.cer is the name of the server certificate, and in the list of X509v3 extensions you should see a section like this:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication

And similarly "TLS Web Client Authentication" for a client certificate. If these aren't present, or if the wrong type is applied (the client EKU on what should be your server's certificate, for example), that would cause those errors.
As an aside, we discovered after we released that sometimes Picnic certificates can grow too large and trigger a bug that causes the TLS session negotiation to fail. Oops! Also, Picnic was the only working PQ signature algorithm in the OpenSSL 1.0.2 fork we use at the time, so it's the only algorithm we've attempted to use. For this reason we're currently using RSA certificates for authentication. Since the pressing need now is to protect the key exchange from future quantum attacks, you can still get some benefit even without a PQ-signed certificate for authentication. Our next release should have this working correctly, and also be able to use the wider variety of PQ signature algorithms that have been added to OQS-OpenSSL since. I suggest you start with RSA certificates (and make sure you apply the correct EKUs!) to get your setup running, and once it is, then you can experiment with certificates signed with PQ signature algorithms.
Please let me know if you have any further questions.

Hello Kevin,
Thank you for your response and all this information, I truly appreciate it.
Well the funny part is that just after my initial message and a system reboot I made, I finally managed to have the PQ algorithms ciphers available to my openvpn install on both windows and linux, so now the openvpn process recognizes them and they show up at the --show-tls ovpn directive.
I set it to use tls version 1.2 as you stated and will keep on testing. The problem now is with openssl, it seems it can't handle the picnicl1fs public keys. It seems that i generate them correctly but openvpn server can't verify them:

Dec 10 09:22:21 scw-cool-borg openvpn[13597]: Tue Dec 10 09:22:21 2019 us=597807 OpenSSL: error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm
Dec 10 09:22:21 scw-cool-borg openvpn[13597]: Tue Dec 10 09:22:21 2019 us=597908 OpenSSL: error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm
Dec 10 09:22:21 scw-cool-borg openvpn[13597]: Tue Dec 10 09:22:21 2019 us=597982 OpenSSL: error:140BF10C:SSL routines:SSL_SET_CERT:x509 lib

Also I get the following openssl issues:

the genoqs command is not resolved
can't apply sha512 digest to the certificates when the public/private keys are on pq algorithms like picnicl1fs and dilithium4

Any more recommendations?
Thanks again for your time so far.

Kevin,
Just a quick update.
I finally managed to run everything correctly on both server and client side and now I am connected to my PQ-VPN. It's exciting!!
I have to report that I managed to do that only on RSA CA, server and client certificate combinations.

Thank you again for your time and information so far. Keep up with it guys, the community needs it.
Best regards,
Alex

I believe the commands for generating OQS PQ key pairs changed in the 1.1 fork, and our instructions are strictly for the 1.0.2 fork. I haven't yet researched how to generate certificates using the 1.1 fork but it should definitely be possible. If you figure it out, by all means please update our instructions and make a pull request.
Make sure your openvpn binary is linking to the OQS-enabled version of OpenSSL instead of the system-installed default. This can be a problem on Linux if you're not careful. Our build scripts set an rpath that should point to versions of OpenSSL installed alongside OpenVPN, but you may want to use ldd to make sure the loader will load those versions rather than the system's default.
Did you verify in your log files that the negotiated ciphersuite is one using a PQ key exchange algorithm once the tunnel is up and running?

Thanks again for the reply,
Yes I confirm I am on the hybrid version of the PQ kex algorithms as you mentioned before. I am pretty sure it works since I always double check the outputs, check if my IP address changed etc. Also I use the tunnel for DNS, which also works perfect.
Concerning the linking to the openssl, here is my openvpn --version output

openvpn --version
liboqs 1.0.0 [git:notices/65fd62a9e8038cf2] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 24 2018
library versions: OpenSSL 1.0.2m-dev  xx XXX xxxx, LZO 2.10

My server system normally uses the openssl installed from the fork, no other versions are installed. (So by openssl'ing anywhere in the system i can produce pq keys etc.) Thanks for clarifying about the genoqs command, because I was wondering why it was not recognized. So now I have made it up to here will step into the picnic pk testing according to the instructions you provided. I will be more than happy if I manage to setup this specific PKI.

You appear to actually be using the 1.0.2 fork of OpenSSL. That version should support the genoqs command in our current documentation.

I think that my actual openssl is 1.1.1d, but the libraries the openvpn reads from are the original (fork ones)

OpenSSL 1.1.1d  10 Sep 2019
built on: Tue Dec 10 08:31:41 2019 UTC
platform: linux-x86_64
options:  bn(64,64) rc4(8x,int) des(int) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Ioqs/include -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/lib/engines-1.1"
Seeding source: os-specific

In that case, it's also likely the algorithms themselves have changed between the two versions, and so a certificate generated with the 1.1 fork would not be usable with the 1.0 fork.

That is right, for now though I confirm that I can work (at least) with RSA certificates.

I also confirm that *PQ-ALGORITHMS-ECDHE-ECDSA are working with ECDSA signed certs.

I successfully managed to set the according openssl version of the guide (1.0.2) to my server and now genoqs works but when everything is done, it stacks in the handshake with excessive message size error. But maybe that is due my system's default openssl (1.1.1d) gonna check it

The excessive message size error is also what I observed, and I think that may just be broken, unfortunately. Until a cryptographically-relevant quantum computer exists, though, we can still safely rely on RSA and ECDSA certificates for authentication, and then you get the PQ-protected key exchange you want now.

I also managed to create Picnic PKI (CA certificate of the Picnic type) and this works if you sign your server and client rsa (and possibly ecdsa also) certificates with that CA.

This suggests validating the certificate chain isn't a problem, but rather something in validating the signature in the ServerKeyExchange message is generating this error, because the Picnic signature in there is too large, which you'll only get if the end-entity certificate has a Picnic public key.

Finally I managed to run PQ-only tls (control channel) negotiation. That happened by using Picnic CA and server certificates and a RSA client certificate signed with Picnic CA. It is also possible this can happen with ECDSA client certificate.

Very interesting. That does narrow down where the problematic section might be. Thanks for spending the time to track down the exact circumstances that cause the failure.
If you find that there is an easy place in the code where we can increase a constant or the size of a buffer to make this work, please consider making a pull request.

Greetings again,
It's been a while since I started using and testing the PQCrypto-VPN and it seems great. The only bad point is that it works only in hybrid mode (OQSKEX - RSA)
It seems that the broken part has to do with openssl's built-in constants / static files, since the error it provides has to do with the TLS negotiation (routines:ssl3_get_message:execssive) and especially the ssl3.h file seems to do this job.
It would be of great help if there are any clues on which file(s) should be changed in order to build the source manually with the right values. I will have the look at the source of PQCrypto-VPN myself and if I figure it out I will make a statement. Also I would like to ask if there is a ready (built or source) version of PQCrypto-VPN at your end which can be used for the testing of the three major PQ-only setups that can negotiate with no buffer error.
Thanks again for your time and help so far.
Warm regards

Unfortunately we don't have a version without this bug, which ends up being triggered by most Picnic certificates. Our plan is to update PQCrypto-VPN to use the latest fork of the Open Quantum Safe project's OpenSSL 1.1 fork, as that will contain the latest versions of all the supported algorithms as well as support for TLS 1.3, when that fork is ready. Our resources are focused on doing that, and so we haven't attempted to figure out where we could patch the current version to work around this problem.
I expect the problem is actually in OpenSSL, and not in PQCrypto-VPN, wherever that length exceeded error is generated, but I don't know that for certain. I don't believe OQS has any plans to go back and patch the 1.0.2 branch to work around this problem, and so for these reasons our plan is simply to do a new release with the updated versions of OQS-OpenSSL and OpenVPN.
If you investigate and discover a quick change can fix this problem, please do let me know and we can look at ways to incorporate it. It just becomes complicated if it requires changes to a repo we depend on but don't have any control over.

Kevin,
Yes updating to openssl 1.1(.1d) would be a great supply because it seems that this last branch has the required fixes on this issue, which also occured in normal older openvpn setups with large-size certificates in the past. It clearly has to do with the built-in openssl configuration used by that setup, and I believe the root of the problem lies within the source of the ssl3.h file which carries the code handling the buffer limits.
Anyway I will be waiting for the updated versions indeed, since I am a fan of PQCrypto since I found it. It would be great if there are other implementations of PQCrypto for other platforms as well (for example Android devices). I have seen that at the moment raspberry is supported. I will be checking the git on regular basis to be sure I am always up to date on it.
Thank you a lot for the time you spent guiding me around and for informing.
Closing this for now but if anything occurs I will get back with a new ticket, pull req. e.t.c.
Best regards

@pqfan I've got a candidate of the 1.3 release ready for you to try out, in the dev-1.3 branch: https://github.com/microsoft/PQCrypto-VPN/tree/dev-1.3
I've moved to using submodules for the various dependencies, so clone with: git clone --branch dev-1.3 --recurse-submodules https://github.com/microsoft/PQCrypto-VPN.git. There's also a Dockerfile under openvpn/build/docker as well. The Windows build is now done completely cross-compiled, so everything gets built in one step now.
Feedback welcome!

Dear Kevin,
Thank you very much for sharing with me. I will start testing this version
right now by your recommendations.
For your information I am currently testing on a Windows 7 Home Premium,
Intel Core i3-2310M @ 2.10Ghz (64-bit)
You will receive my feedback soon, we will be in touch.
Best regards
On Wed, Mar 25, 2020 at 9:10 PM Kevin Kane<EMAIL_ADDRESS>wrote:

@pqfan https://github.com/pqfan I've got a candidate of the 1.3 release
ready for you to try out, in the dev-1.3 branch:
https://github.com/microsoft/PQCrypto-VPN/tree/dev-1.3
I've moved to using submodules for the various dependencies, so clone
with: git clone --branch dev-1.3 --recurse-submodules
https://github.com/microsoft/PQCrypto-VPN.git. There's also a Dockerfile
under openvpn/build/docker as well. The Windows build is now done
completely cross-compiled, so everything gets built in one step now.
Feedback welcome!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PQCrypto-VPN/issues/5#issuecomment-604031500,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN7ZPVAYSISGURD4JBMH6GLRJJJKTANCNFSM4JYJPJMQ
.

Kevin,
I encountered a first issue while building using the git command you told
me. The windows installer built just installs a normal version of openvpn
2.4.8 and not the pqcrypto one.
On Wed, Mar 25, 2020 at 9:32 PM Alexandros Koukoulas <
<EMAIL_ADDRESS>wrote:

Dear Kevin,
Thank you very much for sharing with me. I will start testing this version
right now by your recommendations.
For your information I am currently testing on a Windows 7 Home Premium,
Intel Core i3-2310M @ 2.10Ghz (64-bit)
You will receive my feedback soon, we will be in touch.
Best regards
On Wed, Mar 25, 2020 at 9:10 PM Kevin Kane<EMAIL_ADDRESS>wrote:

@pqfan https://github.com/pqfan I've got a candidate of the 1.3
release ready for you to try out, in the dev-1.3 branch:
https://github.com/microsoft/PQCrypto-VPN/tree/dev-1.3
I've moved to using submodules for the various dependencies, so clone
with: git clone --branch dev-1.3 --recurse-submodules
https://github.com/microsoft/PQCrypto-VPN.git. There's also a Dockerfile
under openvpn/build/docker as well. The Windows build is now done
completely cross-compiled, so everything gets built in one step now.
Feedback welcome!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PQCrypto-VPN/issues/5#issuecomment-604031500,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN7ZPVAYSISGURD4JBMH6GLRJJJKTANCNFSM4JYJPJMQ
.

Please note that you do need to update your configuration files to enforce TLS 1.3 on the control channel; in particular, tls-cipher is no longer relevant because support for PQ algorithms has been removed from TLS 1.2 and below. Instead you add tls-version-min 1.3 to guarantee TLS 1.3, and somewhat unintuitively specify a key exchange algorithm with ecdh-curve like ecdh-curve sikep434. Take a look at the updated configuration files in openvpn/config.
The signature algorithm depends on whatever certificate you provide for authentication, and you'll need to regenerate any certificates as the schemes have changed. But in good news, Picnic certificates do now work!
After I did this, I did get a PQ-protected tunnel from my Windows test system. Can you describe in detail the steps you used to build that resulted in the normal version of OpenVPN?

I launched an Ubuntu 18.04 VM, then after updating, upgrading and
installing python, python3, cmake, ninja-build I ran the git clone --branch
dev-1.3 --recurse-submodules https://github.com/microsoft/PQCrypto-VPN.git
command to clone. After that I went to the openvpn/build subdirectory and
executed sudo python build.py after installing all the recommended
dependencies. The same classic installer and linux files were also
generated building from the Dockerfile.
Also I somehow easily get the "no space left on drive" (or something like
this) error, meaning that with a few runs of the command the drive space is
filled up quickly.
On Thu, Mar 26, 2020 at 6:21 PM Kevin Kane<EMAIL_ADDRESS>wrote:

Please note that you do need to update your configuration files to enforce
TLS 1.3 on the control channel; in particular, tls-cipher is no longer
relevant because support for PQ algorithms has been removed from TLS 1.2
and below. Instead you add tls-version-min 1.3 to guarantee TLS 1.3, and
somewhat unintuitively specify a key exchange algorithm with ecdh-curve
like ecdh-curve sikep434. Take a look at the updated configuration files
in openvpn/config.
The signature algorithm depends on whatever certificate you provide for
authentication, and you'll need to regenerate any certificates as the
schemes have changed. But in good news, Picnic certificates do now work!
After I did this, I did get a PQ-protected tunnel from my Windows test
system. Can you describe in detail the steps you used to build that
resulted in the normal version of OpenVPN?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PQCrypto-VPN/issues/5#issuecomment-604526777,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN7ZPVF4TUTMXJUMJNRY4KTRJN6I3ANCNFSM4JYJPJMQ
.

How strange!
Would you upload the Windows and Linux installers you built as a reply to this issue, so I can take a look at them?

https://drive.google.com/open?id=1Qvc5s6H4vanomynd6sQZUPzXMQVjpg4S
https://drive.google.com/open?id=16E3rTDOMt8sOPN3nCHyLl5ut_7FB7s_K

At first glance I don't see any problems with these binaries. The libraries appear to have the OQS code built in, and I could use both to generate a Picnic signing key, at the very least. What are you seeing that makes you think the OQS code isn't present?

The --show-tls output does not provide any OQS key exchange mechanisms at all, I get a normal openvpn 2.4.8 --show-tls output.

Neither using the Linux binary I can run OQS KEMs in a Linux machine, but I will recheck that now

I understand. There's a critical change here to be aware of: the Open Quantum Safe's fork of OpenSSL 1.1.1 only supports post-quantum algorithms in TLS 1.3. All support for for PQ TLS 1.2 and before has been removed.
In TLS 1.3, the definition of a ciphersuite changed significantly: it no longer specifies the key exchange algorithm or the authentication algorithm, only the symmetric encryption and hash algorithms. This is why the post-quantum key exchange algorithms in TLS 1.3 are masquerading as elliptic curves, and are specified with the ecdh-curve configuration directive.
If you look at the top of the output of openvpn --show-tls, there's a section for TLS 1.3, and there you won't see mention of any of the asymmetric algorithms there, post-quantum or otherwise. And as OQS removed support for TLS 1.2 in this fork, they're all absent from the list of ciphersuites for TLS 1.2.
Right now, it's not obvious from the log output that a PQ key exchange algorithm is being used when OpenVPN starts up. I need to look at adding some logging to include this information. At present I have to verify it's happening by taking a packet capture, and examining the TLS 1.3 handshake, but that's not suitable in general. Similarly, as long as you provide client and server certificates that are using a post-quantum signature algorithm, that algorithm will be used to verify the signatures.
So I think you are able to bring up a completely post-quantum tunnel with the binaries you've built. You just need to make sure your configuration file has been correctly updated. See my previous comments, and the updated examples in openvpn/config.

Great and thanks for explaining, going to check right now and will get back to you to let you know of the results

Ok Kevin, the negotiation is being done just fine as you said, apologies for the mistake too, but there is an error with the TAP driver on my windows, it says that it is being used after the negotiation so the connection closes. Any clues on this? Thanks

I haven't run into this problem before, and I'm not knowledgeable about the TAP driver. I don't think I can help with this.
If you experience the same problem with the official, unmodified version of OpenVPN 2.4.8, so we can be sure our modifications are unrelated, you might try getting advice from the people who maintain it: https://github.com/OpenVPN/tap-windows6

Kevin,
I can connect to the VPN server, via the gui and ssh, but the traffic seems not to be forwarded correctly, so I can not browse the web through the VPN. I suppose that this is not an error with the DNS proxy because I have set everything regarding the firewall dns accordingly as I did with the previous stable version. The last message of the server log is that of:
MULTI: bad source address from client [::], packet dropped
Any suggestions?
Thank you

Ok Kevin, I am working smoothly with it now.
I would like to ask you if this current dev version supports all the current liboqs schemes, meaning all the following algorithms found at the liboqs github page:
Supported Algorithms
Key encapsulation mechanisms
BIKE: BIKE1-L1-CPA, BIKE1-L3-CPA, BIKE1-L1-FO, BIKE1-L3-FO
Classic McEliece: Classic-McEliece-348864†, Classic-McEliece-348864f†, Classic-McEliece-460896†, Classic-McEliece-460896f†, Classic-McEliece-6688128†, Classic-McEliece-6688128f†, Classic-McEliece-6960119†, Classic-McEliece-6960119f†, Classic-McEliece-8192128†, Classic-McEliece-8192128f†
FrodoKEM: FrodoKEM-640-AES, FrodoKEM-640-SHAKE, FrodoKEM-976-AES, FrodoKEM-976-SHAKE, FrodoKEM-1344-AES, FrodoKEM-1344-SHAKE
Kyber: Kyber512, Kyber768, Kyber1024, Kyber512-90s, Kyber768-90s, Kyber1024-90s
LEDAcrypt: LEDAcryptKEM-LT12, LEDAcryptKEM-LT32, LEDAcryptKEM-LT52†
NewHope: NewHope-512-CCA, NewHope-1024-CCA
NTRU: NTRU-HPS-2048-509, NTRU-HPS-2048-677, NTRU-HPS-4096-821, NTRU-HRSS-701
SABER: LightSaber-KEM, Saber-KEM, FireSaber-KEM
SIKE: SIDH-p434, SIDH-p503, SIDH-p610, SIDH-p751, SIKE-p434, SIKE-p503, SIKE-p610, SIKE-p751, SIDH-p434-compressed, SIDH-p503-compressed, SIDH-p610-compressed, SIDH-p751-compressed, SIKE-p434-compressed, SIKE-p503-compressed, SIKE-p610-compressed, SIKE-p751-compressed
ThreeBears: BabyBearEphem, BabyBear, MamaBearEphem, MamaBear, PapaBearEphem, PapaBear

Signature schemes
Dilithium: Dilithium2, Dilithium3, Dilithium4
Falcon: Falcon-512, Falcon-1024
MQDSS: MQDSS-31-48, MQDSS-31-64
Picnic: Picnic-L1-FS, Picnic-L1-UR, Picnic-L3-FS, Picnic-L3-UR, Picnic-L5-FS, Picnic-L5-UR, Picnic2-L1-FS, Picnic2-L3-FS, Picnic2-L5-FS
qTesla: qTesla-p-I, qTesla-p-III
Rainbow: Rainbow-Ia-Classic, Rainbow-Ia-Cyclic, Rainbow-Ia-Cyclic-Compressed, Rainbow-IIIc-Classic†, Rainbow-IIIc-Cyclic†, Rainbow-IIIc-Cyclic-Compressed†, Rainbow-Vc-Classic†, Rainbow-Vc-Cyclic†, Rainbow-Vc-Cyclic-Compressed†
SPHINCS+-Haraka: SPHINCS+-Haraka-128f-robust, SPHINCS+-Haraka-128f-simple, SPHINCS+-Haraka-128s-robust, SPHINCS+-Haraka-128s-simple, SPHINCS+-Haraka-192f-robust, SPHINCS+-Haraka-192f-simple, SPHINCS+-Haraka-192s-robust, SPHINCS+-Haraka-192s-simple, SPHINCS+-Haraka-256f-robust, SPHINCS+-Haraka-256f-simple, SPHINCS+-Haraka-256s-robust, SPHINCS+-Haraka-256s-simple
SPHINCS+-SHA256: SPHINCS+-SHA256-128f-robust, SPHINCS+-SHA256-128f-simple, SPHINCS+-SHA256-128s-robust, SPHINCS+-SHA256-128s-simple, SPHINCS+-SHA256-192f-robust, SPHINCS+-SHA256-192f-simple, SPHINCS+-SHA256-192s-robust, SPHINCS+-SHA256-192s-simple, SPHINCS+-SHA256-256f-robust, SPHINCS+-SHA256-256f-simple, SPHINCS+-SHA256-256s-robust, SPHINCS+-SHA256-256s-simple
SPHINCS+-SHAKE256: SPHINCS+-SHAKE256-128f-robust, SPHINCS+-SHAKE256-128f-simple, SPHINCS+-SHAKE256-128s-robust, SPHINCS+-SHAKE256-128s-simple, SPHINCS+-SHAKE256-192f-robust, SPHINCS+-SHAKE256-192f-simple, SPHINCS+-SHAKE256-192s-robust, SPHINCS+-SHAKE256-192s-simple, SPHINCS+-SHAKE256-256f-robust, SPHINCS+-SHAKE256-256f-simple, SPHINCS+-SHAKE256-256s-robust, SPHINCS+-SHAKE256-256s-simple

Note that algorithms marked with a dagger (†) have large stack usage and may cause failures when run on threads or in constrained environments.
Thank you!

I figured out that the actual algorithms supported are the set of libOQS to be implementhed into OQS OpenSSL, which means that the exact list is currently the following:
Supported Algorithms
If an algorithm is provided by liboqs but is not listed below, it can still be used in the fork through either one of two ways.
Key Exchange
The following quantum-safe algorithms from liboqs are supported (assuming they have been enabled in liboqs):
oqs_kem_default (see here for what this denotes)
BIKE: bike1l1cpa, bike1l3cpa, bike1l1fo, bike1l3fo
FrodoKEM: frodo640aes, frodo640shake, frodo976aes, frodo976shake, frodo1344aes, frodo1344shake
Kyber: kyber512, kyber768, kyber1024
NewHope: newhope512cca, newhope1024cca
NTRU: ntru_hps2048509, ntru_hps2048677, ntru_hps4096821, ntru_hrss701
Saber: lightsaber, saber, firesaber
SIDH and SIKE: sidhp434, sidhp503, sidhp610, sidhp751, sikep434, sikep503, sikep610, sikep751

The following hybrid algorithms are supported only for L1 schemes; they combine an L1 quantum-safe algorithm listed above with ECDH that uses NIST's P256 curve:
p256_<KEX>, where <KEX> is any one of the L1 algorithms listed above.

Authentication
The following digital signature algorithms from liboqs are supported (assuming they have been enabled in liboqs):
oqs_sig_default (see here for what this denotes)
Dilithium: dilithium2, dilithium3, dilithium4 (not currently on Windows)
Picnic: picnicl1fs
qTesla: qteslapi, qteslapiii

The following hybrid algorithms are supported; they combine a quantum-safe algorithm listed above with a traditional digital signature algorithm ( is any one of the algorithms listed above):
if <SIG> has L1 security, then the fork provides the methods rsa3072_<SIG> and p256_<SIG>, which combine <SIG> with RSA3072 and with ECDSA using NIST's P256 curve respectively.
if <SIG> has L3 security, the fork provides the method p384_<SIG>, which combines <SIG> with ECDSA using NIST's P384 curve.
if <SIG> has L5 security, the fork provides the method p521_<SIG>, which combines <SIG> with ECDSA using NIST's P521 curve.

Pretty good work Kevin, keep it up, and since things will change soon, after the NIST pq competition evaluation etc. try to always update the used liboqs libraries in every dev/stable version!

Regarding your networking issues: You will need to do some network setup on the server side to route traffic to the other side, but since I don't know your networking setup I can't help you with this directly. For most people, if your OpenVPN server is a single host with a single IP address, you need to set up the same kind of NAT masquerading you would need to do for a home internet connection. OpenVPN has some documentation to help you get started: https://community.openvpn.net/openvpn/wiki/BridgingAndRouting
Regarding the supported algorithms, we should support whatever algorithms are supported by OQS-OpenSSL, and the keywords you can use with ecdh-curve are from the list you found of its supported algorithms.
As for what's supported, that's up to the OQS team, not us. If you've noticed some schemes work on Windows that they don't think should, please raise an issue on their issue tracker to let them know!
I plan to update and do our formal release when the OQS team next makes stable releases of liboqs and OpenSSL. Beyond that, we'll have to see. We won't be able to constantly update to be in sync with their development branch, but I expect we can update whenever they hit a significant milestone that's both stable and has significant new features added.

Closing this issue. If you run into further issues or have more questions, feel free to open new issues, or reopen this one with further comments, as appropriate.


mv binstar.org anaconda.org

@LilaHickey @srossross what do you think?
The only thing I'm not changing is alpha.binstar.org because we don't have a alpha.anaconda.org

LGTM


Missing functionality - Storage > Backups

Fixes https://github.com/apache/cloudstack-primate/issues/215

@rhtyd cc @svenvogel
I've completed fix. Please review!

This is duplicate effort, a PR already exists https://github.com/apache/cloudstack-primate/pull/64
@utchoang please don't do any further work on this.


query in Energy Based GAN (EBGAN)

Hi
Thank you for your wonderful effort in implementing so many papers.
I have a query regarding your EBGAN implementation.
https://github.com/eriklindernoren/PyTorch-GAN/blob/master/implementations/ebgan/ebgan.py
In line 175 when you are optimizing the generator G why is the pixelwise_loss computed using gen_imgs.detach() and why not simply gen_imgs() ? If we do .detach() while updating G then the pixelwise_loss will not contribute any gradients towards optimizing the generator weights. Is it the right way to do that ?
Please clarify my doubt.
Thank You in Advance !

Because we use gen_imgs as the target variable in that case. The generator is updated according to the recon_imgs output.

Thank you for your prompt reply ! It is an excellent catch. But does that mean that the Generator outputs gen_imgs are not directly being used to drive any weight updates but rather indirectly used when we use the reconstructions of the generated outputs i.e. recon_imgs?

Sorry for the late response. Yes, your observation is correct. :)


Add TryPartial to unsafe warts list in README

As far as I understand from https://github.com/puffnfresh/wartremover/blob/v0.13/core/src/main/scala/wartremover/warts/Unsafe.scala TryPartial is part of the unsafe warts list.

I think you want to merge this into master, not latest-release.

I guess I could pull request it to master, but also backport it to latest release seeing as it's what's present in the latest release.

@puffnfresh I think this needs changing in both master and latest-release, as it's currently present in both, what do you think?


Clear existing versions when adding OSS-Fuzz fix.

Otherwise we could have a race condition where we include versions that
may include the fix.

tbr


GPKG layer with dash causes an error

This code works but prints an SQLite error that it can't delete trigger rtreee_<layer_name> because of syntax error at "-" -- the name of the trigger is unquoted, and dash is a minus sign.
In GDAL this error has been fixed years ago, and my version is much newer (3.2) than then (2.0). What's going on and is it possible to fix this?
use std::path::Path;
use gdal::{Dataset, DatasetOptions, GdalOpenFlags};
use gdal::vector::FieldValue;

fn main() {
	let dso = DatasetOptions { open_flags: GdalOpenFlags::GDAL_OF_READONLY | GdalOpenFlags::GDAL_OF_UPDATE, allowed_drivers: Some(&["GPKG", "GeoJSON"]), open_options: None, sibling_files: None };
	let dataset = Dataset::open_ex(Path::new("flat-sale.gpkg"), dso).expect("failed to open gpkg file");

	let mut layer = dataset.layer(0).unwrap();
	let mut area:f64 = 0.0;
	let mut rows:i32 = 0;
	for feature in layer.features() {
		let highway_field = feature.field("total_area").unwrap().unwrap();
		rows += 1;
		match highway_field {
			FieldValue::IntegerValue(i) => { area += i as f64; },
			FieldValue::Integer64Value(i) => { area += i as f64; },
			FieldValue::RealValue(i) => { area += i; },
			_ => {}
		}
	}
	println!("AREA {:?} ROWS {} MEAN AREA {}", area, rows, area / rows as f64);
}

Output:
ERROR 1: sqlite3_exec(DROP TRIGGER rtree_flat-sale_geom_update3) failed: near "-": syntax error
ERROR 1: sqlite3_exec(CREATE TRIGGER "rtree_flat-sale_geom_update3" AFTER UPDATE ON "flat-sale"
WHEN OLD."fid" != NEW."fid" AND (NEW."geom" NOTNULL AND NOT ST_IsEmpty(NEW."geom")) BEGIN
DELETE FROM "rtree_flat-sale_geom" WHERE id = OLD."fid"; INSERT OR REPLACE INTO "rtree_flat-sale_geom"
VALUES (NEW."fid",ST_MinX(NEW."geom"), ST_MaxX(NEW."geom"),ST_MinY(NEW."geom"), ST_MaxY(NEW."geom"));
END) failed: trigger "rtree_flat-sale_geom_update3" already exists

AREA 59143095.80000853 ROWS 996284 MEAN AREA 59.36369127679309
1 seconds

I tried, but I couldn't reproduce it with a simplified version of the code:
use gdal::vector::FieldValue;
use gdal::{Dataset, DatasetOptions, GdalOpenFlags};
use std::path::Path;

fn main() {
    let dso = DatasetOptions {
        open_flags: GdalOpenFlags::GDAL_OF_READONLY | GdalOpenFlags::GDAL_OF_UPDATE,
        allowed_drivers: Some(&["GPKG", "GeoJSON"]),
        open_options: None,
        sibling_files: None,
    };
    let dataset = Dataset::open_ex(Path::new("a-b.gpkg"), dso).expect("failed to open gpkg file");

    let mut layer = dataset.layer(0).unwrap();
    let mut rows: i32 = 0;
    for feature in layer.features() {
        rows += 1;
    }
    println!("ROWS {}", rows);
}

In any case, it sounds like a GDAL and/or SQLite issue. Can you test in a Docker container like osgeo/gdal:ubuntu-full-3.2.0?

GDAL upstream issue just fixed per https://github.com/OSGeo/gdal/commit/9452625baa544ea3ab6bb0b3e368023434011ea7

Fixed upstream, thanks Even. My reproduction didn't work because my table name probably didn't actually contain a dash.

My reproduction didn't work because my table name probably didn't actually contain a dash.

more subtle than that: the table name must contain a dash and have been created with the buggy triggers as defined in the GeoPackage < 1.2.1 spec (so with a quite ancient GDAL version)


Added description fields to swagger doc.

Just add a 'description' field in each validation rule in settings.py

@nicolaiarocci I get a weird behavior now on my production server where it complains about:
...
...
9/13/2016 12:50:18 PM  File "/usr/local/lib/python2.7/dist-packages/cerberus/cerberus.py", line 175, in __init__
9/13/2016 12:50:18 PM    self.validate_schema(self.schema)
9/13/2016 12:50:18 PM  File "/usr/local/lib/python2.7/dist-packages/cerberus/cerberus.py", line 451, in validate_schema
9/13/2016 12:50:18 PM    constraint, field))
9/13/2016 12:50:18 PMSchemaError: unknown rule 'description' for field 'description'

But on my development server it was working fine.
I'm using Eve 0.6.4 and Cerberus 0.9.2 (both pip installed) and I'm scrambling now to figure why I have this discrepancy.
It seems that Cerberus does not like "random" keys in the validation rules.  Is there a way to make him ignore them?  Initial I thought Eve's ALLOW_UNKNOWN would be a solution, but this should not work because the issue is NOT allowing unknown resource attributes to be submitted but for Cerberus to allow arbitrary fields in the validation rules.
Any ideas what switches to use? Or where to patch it?
Also is this considered a Cerberus "bug"?

OK, gotta turn on TRANSPARENT_SCHEMA_RULES on settings.py.  Apparently this was by default on in an older version of Eve?

Merged after rebase, see 253088f


Implement "authenticationToken" in website.conf

Use uuid4 probably to generate a token for dynamically built push packages

Done in 0.1.0


Update data-storage.md to include the limit on document IDs lengths.

update the document to include the limit on document IDs lengths.

@chcomley

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

#sign-off


fix(module:select): error caused by value of sync

PR Checklist
Please check if your PR fulfills the following requirements:

[X] The commit message follows our guidelines: https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: #326
What is the new behavior?
Does this PR introduce a breaking change?
[ ] Yes
[X] No

Other information

Coverage increased (+0.01%) to 40.784% when pulling 931ec1c7d208ce69a06887f8633696aa32e45813 on HsuanXyz:fix-multiple-select into 6e4794b39b87f89607490fe1f0b60c63fe5402fd on NG-ZORRO:master.


Database Performance Improvements

during correlation each event is pulled then pushed back to the DB including all of the document that already exists. This can be improve by using Mongo array commands to push only the updates.
Furthermore, CPU can be hit hard with the  correlation engine and it would be wroth looking at how the number of loops can be reduced.

Further testing of this has also shown a slow down in the performance of correlations when the events in the system exceed 10k currently active


APIM 3.1.0 installation guide link on Analytics page return 404 not found

Description:
Installation Guide in this page is a 404 - https://apim.docs.wso2.com/en/latest/learn/analytics/configuring-apim-analytics/
Steps to reproduce:

Go to docs.wso2.com, and click on APIM 3.1.0 docs
Click on Analytics in bottom right hand corner
Click on 'Setup and Configuration' under Analytics
Click on 'Configure APIM Analytics'
Click on 'Installation Guide' (1st step) under Quick Setup

Gives page not found error

This documentation has been revamped and fixed the issue for the latest APIM releases

@AnuGayan This issue is still not fixed. I just tried the repro steps and it's still giving me a 404. I'm specifically talking about APIM 3.1.0 here. Not the latest version.

Hi @wx-yz We have fixed this from the above PR,
Please check on an incognito browser window.


Report a bug not showing sent with githawk

If you report a bug there’s no sent with githawk signature. Not sure why.
Sent with GitHawk

Correction. It did appear this time.
Here’s a picture of my other one.
Maybe I did New Issue for that one.

Sent with GitHawk

Could have to do with the fact that I copied and pasted my body text. Not sure.
Sent with GitHawk

There might be a diff between the report bug via settings and report bug via repo? What is the expected behavior here?

I expected to show the githawk symbol.
I honestly have no clue where I reported the bugs from each time. :/
Sent with GitHawk

Report a bug doesn't append the signature. "New Issue" does.
https://github.com/GitHawkApp/GitHawk/blob/master/Classes/New Issue/NewIssueTableViewController.swift#L38
I think this is fine.

Oh okay cool.
Sent with GitHawk


Posting from the BlueSky snippet raises errors with some text patterns

The very first message I tried to post was:
In strict conformance with the Scientific Method (note the capitalization!), I verify @tudorgirba.com 's affirmation that I can post to BlueSky from Glamorous Toolkit by myself. If you see this text, it works for me.

This raises an exception because something went wrong with processing the handle:

I edited the text to remove the handle, and then wrote a second message about the error message. But app.bsky.feed.post also got parsed into a facet (whatever that is), and led to the same error message again.


refactor!: update secret path to secretName

BREAKING CHANGE: updated secret path to secretName

If your build fails  due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/main/.github/Contributing.md
PR Checklist
Please check if your PR fulfills the following requirements:

[ ] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[ ] I am not introducing a new dependency (add notes below if you are)
[ ] I have added unit tests for the new feature or bug fix (if not, why?)
[x] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
[ ] I have opened a PR for the related docs change (if not, why?)

Testing Instructions
make tidy
make test
make docker
New Dependency Instructions (If applicable)

Codecov Report

Merging #238 (ac6de9f) into main (4a9e67f) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main     #238   +/-   ##
=======================================
  Coverage   31.77%   31.77%
=======================================
  Files          18       18
  Lines        1822     1822
=======================================
  Hits          579      579
  Misses       1179     1179
  Partials       64       64

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Observed below two issues during validation:
1.Using map_credentials.sh script it adds credentials at writable/insecuresecrets/secretname/secrets.
authorization does not work by adding credentials at above path. I tried manually adding credentials in consul at writable/insecuresecrets/secrets/secretdata. With this authorization does work correctly for camera(s). All utility scripts (map_credentials, edit_credentials etc) need to be updated with 'SecretName' instead of secretpath.
2. after adding credentials, I have to restart onvif service for authorization work. This needs to be investigated and resolved.

the script bin/utils.sh: https://github.com/edgexfoundry/device-onvif-camera/blob/main/bin/utils.sh#L505 line has json path. Question: is this json data ok?

Validation still does not look good.
Not authorizing cameras until user restarts onvif service. also after its authorizing it did not add at least one authorized camera to metadata successfully. attached logs.
_edgex-device-onvif-camera_logs (47).txt

Validation still does not look good. Not authorizing cameras until user restarts onvif service. also after its authorizing it did not add at least one authorized camera to metadata successfully. attached logs. _edgex-device-onvif-camera_logs (47).txt

thanks for testing, can you share steps how you get to this error, do you need real camera to test it?

@vyshali-chitikeshi , the request failed, status code: 503, err: HTTP request timeout" errors are from the know issue, which I have a fix for going in today. The fix is in Core Metadata's Add Device. I don't see any errors accessing the secrets, which this PR impacts with the renaming of fields. Lets retest once my Core Metadata fix is ready and see if that helps clear up other issue also.


{BUG}: REMOVE EXTRA UI

HI , @vishanurag

Currently your code show this type extra icon. i want to work on this.

and in footer section display some extra code. i want work on this.
Under Gssoc'24. please assign me for this issuse.

The similar issues are already assigned or resolved.


Missing tags for releases

Please add tags for releases to the git repo.

I see. 2.2.0 is actually tagged, but its inconsistent with scheme used for previous tags (e.g., "v2.1.5")

Thanks for the call out @bollig, we'll update the tag to follow the same schema.

Hi @bollig, the tag is updated to v2.2.0, you should be able to get the update with git pull --prune --tags. Thanks for the call out!


+2 icons

Description
Add 2 apps' icon to Lawnicons.
Icons addition information

Added

Rizline (com.PigeonGames.Rizline)
律动轨迹 ~~ Rizline (com.leiting.ldgj)
Contributor's checklist

[x] I followed the Lawnicons guidelines and will make changes if someone suggests. I will also make sure that Lawnicons builds correctly.

Sorry for closing and reopening, I thought I made a mistake, but I didn't.
(I'm using a translator, so my grammar may be wrong.)

The icons are too small. They are not square, so the size should be larger.
I also suggest making the lightning bolt 2 times larger in the Chinese version so that it does not look like a black dot on the phone. Although lightning bolt is hardly important and you can link both apps to rizline.svg.

I can't work on this now, and this is my first time making something like this, so I might make a mistake
I might do this in a couple days


Support for large BARs in PCI devices

Our current implementation does not support 64 bit BARs (bits 1:0 == 10).
We need to:

Combine two BARs and return a 64 bit address range.
Make sure we only update address ranges when BAR update is complete (not for partial writes)

Implemented on:
https://gem5-review.googlesource.com/c/public/gem5/+/22082


added deals blog

I added my blog!

thank you for your contribution, but i think deals blog does not fit the our project. because we try to gather experience from users. thank you for your interest.

i removed the deals one but kept the tech blog


Rerun

Adding rerun command

Pull Request Test Coverage Report for Build 798

38 of 43 (88.37%)  changed or added relevant lines in 3 files are covered.
53 unchanged lines in 16 files lost coverage.
Overall coverage increased (+0.02%) to 88.151%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

datmo/cli/command/run.py
36
38
94.74%

datmo/cli/main.py
0
3
0.0%

Files with Coverage Reduction
New Missed Lines
%

datmo/cli/command/base.py
1
92.96%

datmo/snapshot.py
1
83.33%

datmo/core/controller/file/driver/local.py
2
91.76%

datmo/cli/command/datmo_command.py
2
100.0%

datmo/core/util/i18n.py
2
100.0%

datmo/cli/command/run.py
2
74.62%

datmo/task.py
2
93.28%

datmo/core/controller/code/driver/file.py
2
95.45%

datmo/cli/command/snapshot.py
2
100.0%

datmo/cli/command/session.py
2
95.7%

Totals

Change from base Build 792:
0.02%

Covered Lines:
3943

Relevant Lines:
4473

💛  - Coveralls


Set the content type to text/html for haml files and text/css for sass

Some older browsers misinterpreted the content type of our compiled html without this.

Thanks for the PR! Can you write some quick specs for this, please? :)


Auto update config for prediction

I added two more commits. @blazekadam, could you please review them?


Describing genetic variations

We wanted to find out if SO is the place for a “genetic variation type” term or should it go in EDAM (under “genetic variation”) .  There can be many “types” of genetic variations e.g. whole gene introductions/deletions, indels, cassettes (other mobile elements), SNVs. Our project (Genepio.org) needs an ontology class to encompass such types. We would start with 2 - gene present and SNV(s) present
If genetic variation types should go in SO, can SO introduce the EDAM “genetic variation” term, and the “genetic variation type” be a subclass in SO?
We also need genetic variation datums to describe the positions of the nucleotide or amino acid changes detected (this is usually done with reference to a known genome, or “reference genome”). The position and nature of the change is usually denoted using a notation system e.g. HGVS.  Should the “nucleotide mutation symbol” (e.g. NC_000023.10:g.33038255C>A) and “amino acid mutation symbol” (e.g. LRG_199p1:p.Trp24Cys) also go in SO? These are shorthand notations for where the mutations occur in a sequence. Different notation systems could be used.
Thanks for advice!
c/o Emma @griffie

I do not believe that SO is the right place for the genetic variation datums you described. SO is primarily concerned with terms that describe pieces of knowledge associated with extents of biological sequence. SO does not capture specific data points associated with a particular database, genome build, ID system, etc. The terms and relationships found within SO can help to inform those efforts, however. While SO won't have nucleotide mutation symbol as a term, SO attempts to capture the different types of mutations that can occur to a given sequence of nucleotides or amino acids. Those terms and relationships would then enable another group to attach data/metadata to those concepts in a way that's consistent with SO and (hopefully) the rest of the sequence annotation community at-large.
Regarding gene present and SNV(s) present variations, it would seem that your terms might fit somewhere under sequence_variant (SO:0001060) but we'd need to do a bit of work to more precisely characterize and document your proposed terms before we could actually create new terms. There is a fairly good chance that there is an existing term that we could edit/update to serve your needs. Is this something you'd be willing to explore?


how to use openlayers to show my own map in a web page

Hi All,
this is the first time to know a bout openlayers so i wanna know how can i use openlayers to show my own map in my web site
thanks

this question is too generic, first check out the docs http://openlayers.org/en/latest/doc/quickstart.html and if something is still not clear ask on stackoverflow instead with tag openlayers


Revert "[TACHYON-473] Remove System Properties use in integration tests"

Reverts amplab/tachyon#954

@calvinjia  Revert this since it breaks master's build.

https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Master/


extern const uint8_t Sample16kHz_raw_start[] asm("_binary_Sample16kHz_raw_start");

Hello,
could you tell me what these codes means exactly?
I just know "extern const uint8_t Sample16kHz_raw_start[]", but what "asm("_binary_Sample16kHz_raw_start")" means?
extern const uint8_t Sample16kHz_raw_start[] asm("_binary_Sample16kHz_raw_start");
extern const uint8_t Sample16kHz_raw_end[]   asm("_binary_Sample16kHz_raw_end");
Thank you

Hello,
it's a way to include binary files inside the program.
Using objcopy you can convert any binary file into .o object, and link with your program using ld.
https://balau82.wordpress.com/2012/02/19/linking-a-binary-blob-with-gcc/
Br.


fix(dom): add better typings for the hyperscript helpers

[ ] There exists an issue discussing the need for this PR
[ ] I added new tests for the issue I fixed or built
[x] I used pnpm run commit instead of git commit

These bad typings are the reason why the zombie transposition could survive for so long in the tests

Looks good. I have just one question about this: is it a breaking change? Technically because people had any types before, with this change, their TypeScript compiler might light up with many errors.

It should not be as all valid uses of the hyperscript helpers are captured in the types. So if this now throws an error where it did not before, then because of a misuse of the API (like transposition).

one nice thing to do would be to merge https://github.com/snabbdom/snabbdom/pull/325 first, to remove the any in the typings

@staltz the snabbdom PR may take ages to be released, let's merge and release this now with any, we can still improve the typings in the future

Okay, how about CI?

Should be fixed now

yes, CI is green

Can you merge? I'm on mobile


Format code with fish_indent

Mainly just tabs converted to spaces.

fish_indent produces a different output for me. For example:
    set -g __done_initial_window_id ''
    set -q __done_min_cmd_duration
    or set -g __done_min_cmd_duration 5000
    set -q __done_exclude
    or set -g __done_exclude 'git (?!push|pull)'
    set -q __done_notify_sound
    or set -g __done_notify_sound 0

Are you on fish master?
On Thu, Dec 5, 2019, 01:09 Francisco Lourenço<EMAIL_ADDRESS>wrote:

fish_indent produces a different output for me. For example:
set -g __done_initial_window_id ''
set -q __done_min_cmd_duration
or set -g __done_min_cmd_duration 5000
set -q __done_exclude
or set -g __done_exclude 'git (?!push|pull)'
set -q __done_notify_sound
or set -g __done_notify_sound 0

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/franciscolourenco/done/pull/62?email_source=notifications&email_token=AE3TXY2QIYZUNVHU4BFE5MDQW7I25A5CNFSM4JTIVCN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5RGAI#issuecomment-561713921,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE3TXY43IZBKCHDLRPSC7OTQW7I25ANCNFSM4JTIVCNQ
.

Hmm, are you on fish master?
The difference you're seeing is probably due to 15c50703ce446b131eb3154bfa3e9596d0bbd74f

3.0.2

I think it would make sense to use the formatter of the latest released version. What do you think?

or wait until the next version

The next version will hopefully be out soon so I think it's OK to use the new formatter now.
Also, if we format with the 3.0.2 version it will remove the semicolons in favour of newlines, but when you run the new formatter after that it won't revert the change so I think it's better to just run the new formatter now and keep the current code style which the new formatter allows.

The only point of running the formatter is if we all use the same formatter all the time. I don't necessarily want to build and install fish from source, so the only formatter I would run is the one currently on stable.
That being said, you are the one doing the most changes lately, so no harm done. If you re-submit the PR without conflicts I would merge right away. Thanks!

thanks!


Update dependency @types/exorcist to v2.0.2

This PR contains the following updates:

Package
Type
Update
Change

@types/exorcist (source)
devDependencies
patch
2.0.1 -> 2.0.2

Configuration
📅 Schedule: Branch creation - "before 4am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Self-Hosted Renovate Bot. Find all logs here.

 You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.


CI: GKE: DNS 'testds-service.default.svc.cluster.local' is not ready after timeout: 7m0s timeout expired"

Observed in at least the following tests:

K8sServicesTest Bookinfo Demo Tests bookinfo demo
K8sChaosTest Connectivity demo application Endpoint can still connect while Cilium is not running
K8sKafkaPolicyTest Kafka Policy Tests KafkaPolicies

(Above three are from same cluster run)
Bookinfo example failure
6a65889e_K8sServicesTest_Bookinfo_Demo_Tests_bookinfo_demo.zip
Stacktrace
/home/jenkins/workspace/Cilium-PR-K8s-GKE@2/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:514
DNS entry is not ready after timeout
Expected
    <*errors.errorString | 0xc0007b05a0>: {
        s: "DNS 'productpage.default.svc.cluster.local' is not ready after timeout: 7m0s timeout expired",
    }
to be nil
/home/jenkins/workspace/Cilium-PR-K8s-GKE@2/src/github.com/cilium/cilium/test/k8sT/Services.go:2483

Standard Output
Number of "context deadline exceeded" in logs: 0
Number of "level=error" in logs: 0
Number of "level=warning" in logs: 0
Number of "Cilium API handler panicked" in logs: 0
Number of "Goroutine took lock for more than" in logs: 0
No errors/warnings found in logs
Number of "context deadline exceeded" in logs: 0
Number of "level=error" in logs: 0
Number of "level=warning" in logs: 0
Number of "Cilium API handler panicked" in logs: 0
Number of "Goroutine took lock for more than" in logs: 0
No errors/warnings found in logs
Number of "context deadline exceeded" in logs: 0
Number of "level=error" in logs: 0
Number of "level=warning" in logs: 4
Number of "Cilium API handler panicked" in logs: 0
Number of "Goroutine took lock for more than" in logs: 0
Top 1 errors/warnings:
Unable to update ipcache map entry on pod add
Cilium pods: [cilium-6dbvq cilium-7t5sr]
Netpols loaded:
CiliumNetworkPolicies loaded:
Endpoint Policy Enforcement:
Pod                                                         Ingress   Egress
grafana-7fd557d749-xb75b
kube-dns-7c976ddbdb-fd88z
reviews-v2-6588f4df97-t8hmb
fluentd-gke-scaler-cd4d654d7-8brx9
kube-dns-7c976ddbdb-gtmv4
metrics-server-v0.3.6-64655c969-qwrft
stackdriver-metadata-agent-cluster-level-5d5694494c-cgh42
prometheus-d87f8f984-jvc7m
productpage-v1-5c79cf49d-rxf4b
reviews-v1-75cfdb45f-dtfxj
l7-default-backend-678889f899-mzbq4
ratings-v1-6bbfd59bf-npxt2
event-exporter-gke-8489df9489-6zwht
kube-dns-autoscaler-645f7d66cf-rngdp
details-v1-6675f948f7-5c6rr
Cilium agent 'cilium-6dbvq': Status: Ok  Health: Ok Nodes "" ContinerRuntime:  Kubernetes: Ok KVstore: Ok Controllers: Total 21 Failed 0
Cilium agent 'cilium-7t5sr': Status: Ok  Health: Ok Nodes "" ContinerRuntime:  Kubernetes: Ok KVstore: Ok Controllers: Total 33 Failed 0

Standard Error
00:25:01 STEP: Running BeforeAll block for EntireTestsuite K8sServicesTest Bookinfo Demo
00:25:01 STEP: Creating objects in file<EMAIL_ADDRESS>00:25:02 STEP: Creating objects in file<EMAIL_ADDRESS>00:25:03 STEP: Waiting for pods to be ready
00:25:03 STEP: WaitforPods(namespace="default", filter="-l zgroup=bookinfo")
00:25:48 STEP: WaitforPods(namespace="default", filter="-l zgroup=bookinfo") => <nil>
00:25:51 STEP: Waiting for services to be ready
00:25:53 STEP: Validating DNS without Policy
FAIL: DNS entry is not ready after timeout
Expected
    <*errors.errorString | 0xc0007b05a0>: {
        s: "DNS 'productpage.default.svc.cluster.local' is not ready after timeout: 7m0s timeout expired",
    }
to be nil
=== Test Finished at 2020-10-31T00:32:53Z====
00:32:53 STEP: Running JustAfterEach block for EntireTestsuite K8sServicesTest
===================== TEST FAILED =====================
00:32:55 STEP: Running AfterFailed block for EntireTestsuite K8sServicesTest
cmd: kubectl get pods -o wide --all-namespaces
Exitcode: 0
Stdout:
 	 NAMESPACE           NAME                                                        READY   STATUS    RESTARTS   AGE     IP              NODE                                          NOMINATED NODE   READINESS GATES
	 cilium-monitoring   grafana-7fd557d749-xb75b                                    1/1     Running   1          114m    <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 cilium-monitoring   prometheus-d87f8f984-jvc7m                                  1/1     Running   1          114m    <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 cilium              cilium-6dbvq                                                1/1     Running   0          12m     <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 cilium              cilium-7t5sr                                                1/1     Running   0          12m     <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 cilium              cilium-node-init-hlrvq                                      1/1     Running   0          12m     <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 cilium              cilium-node-init-jv2kx                                      1/1     Running   0          12m     <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 cilium              cilium-operator-7bf98cd8b5-hx6cx                            1/1     Running   0          12m     <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 cilium              cilium-operator-7bf98cd8b5-k447m                            1/1     Running   0          12m     <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 cilium              log-gatherer-25fft                                          1/1     Running   0          114m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 cilium              log-gatherer-8xfhl                                          1/1     Running   0          114m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 default             details-v1-6675f948f7-5c6rr                                 1/1     Running   0          8m      <IP_ADDRESS>     gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 default             productpage-v1-5c79cf49d-rxf4b                              1/1     Running   0          8m      <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 default             ratings-v1-6bbfd59bf-npxt2                                  1/1     Running   0          7m59s   <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 default             reviews-v1-75cfdb45f-dtfxj                                  1/1     Running   0          8m      <IP_ADDRESS>     gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 default             reviews-v2-6588f4df97-t8hmb                                 1/1     Running   0          7m59s   <IP_ADDRESS>     gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         event-exporter-gke-8489df9489-6zwht                         2/2     Running   0          112m    <IP_ADDRESS>     gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         fluentd-gke-57sj9                                           2/2     Running   0          115m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         fluentd-gke-scaler-cd4d654d7-8brx9                          1/1     Running   1          162m    <IP_ADDRESS>       gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         fluentd-gke-wz2rq                                           2/2     Running   0          114m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         gke-metrics-agent-69wzq                                     1/1     Running   0          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         gke-metrics-agent-f6qjn                                     1/1     Running   0          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         kube-dns-7c976ddbdb-fd88z                                   4/4     Running   0          42m     <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         kube-dns-7c976ddbdb-gtmv4                                   4/4     Running   0          42m     <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         kube-dns-autoscaler-645f7d66cf-rngdp                        1/1     Running   1          162m    <IP_ADDRESS>     gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         kube-proxy-gke-cilium-ci-20-cilium-ci-20-2437f719-83df      1/1     Running   0          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         kube-proxy-gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9      1/1     Running   0          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         l7-default-backend-678889f899-mzbq4                         1/1     Running   1          162m    <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         metrics-server-v0.3.6-64655c969-qwrft                       2/2     Running   2          116m    <IP_ADDRESS>      gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         prometheus-to-sd-6g2f2                                      1/1     Running   0          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         prometheus-to-sd-cjtxz                                      1/1     Running   0          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         registry-adder-2sxzk                                        1/1     Running   1          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-83df   <none>           <none>
	 kube-system         registry-adder-l6t2l                                        1/1     Running   0          116m    <IP_ADDRESS>   gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>
	 kube-system         stackdriver-metadata-agent-cluster-level-5d5694494c-cgh42   2/2     Running   3          116m    <IP_ADDRESS>     gke-cilium-ci-20-cilium-ci-20-2437f719-r2w9   <none>           <none>

Stderr:

Fetching command output from pods [cilium-6dbvq cilium-7t5sr]
cmd: kubectl exec -n cilium cilium-6dbvq -- cilium service list
Exitcode: 0
Stdout:
 	 ID   Frontend              Service Type   Backend
	 1    <IP_ADDRESS>:80       ClusterIP      1 => <IP_ADDRESS>:8080
	 2    <IP_ADDRESS>:31321   NodePort       1 => <IP_ADDRESS>:8080
	 3    <IP_ADDRESS>:31321         NodePort       1 => <IP_ADDRESS>:8080
	 4    <IP_ADDRESS>:443      ClusterIP      1 => <IP_ADDRESS>:443
	 5    <IP_ADDRESS>:443       ClusterIP      1 => <IP_ADDRESS>:443
	 6    <IP_ADDRESS>:3000     ClusterIP      1 => <IP_ADDRESS>:3000
	 7    <IP_ADDRESS>:53       ClusterIP      1 => <IP_ADDRESS>:53
	                                           2 => <IP_ADDRESS>:53
	 8    <IP_ADDRESS>:9090     ClusterIP      1 => <IP_ADDRESS>:9090
	 12   <IP_ADDRESS>:9080    ClusterIP      1 => <IP_ADDRESS>:9080
	 13   <IP_ADDRESS>:9080    ClusterIP      1 => <IP_ADDRESS>:9080
	                                           2 => <IP_ADDRESS>:9080
	 14   <IP_ADDRESS>:9080    ClusterIP      1 => <IP_ADDRESS>:9080
	 15   <IP_ADDRESS>:9080     ClusterIP      1 => <IP_ADDRESS>:9080

Stderr:

cmd: kubectl exec -n cilium cilium-6dbvq -- cilium endpoint list
Exitcode: 0
Stdout:
 	 ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                                  IPv6   IPv4          STATUS
	            ENFORCEMENT        ENFORCEMENT
	 935        Disabled           Disabled          1          k8s:cilium.io/ci-node=k8s2                                                        ready
	                                                            k8s:cloud.google.com/gke-nodepool=cilium-ci-20
	                                                            k8s:cloud.google.com/gke-os-distribution=cos
	                                                            reserved:host
	 1470       Disabled           Disabled          4          reserved:health                                                     <IP_ADDRESS>    ready
	 3302       Disabled           Disabled          28243      k8s:app=reviews                                                     <IP_ADDRESS>   ready
	                                                            k8s:io.cilium.k8s.namespace.labels.istio-injection=enabled
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.kubernetes.pod.namespace=default
	                                                            k8s:version=v2
	                                                            k8s:zgroup=bookinfo

Stderr:

cmd: kubectl exec -n cilium cilium-7t5sr -- cilium service list
Exitcode: 0
Stdout:
 	 ID   Frontend              Service Type   Backend
	 1    <IP_ADDRESS>:443      ClusterIP      1 => <IP_ADDRESS>:443
	 2    <IP_ADDRESS>:443       ClusterIP      1 => <IP_ADDRESS>:443
	 3    <IP_ADDRESS>:9090     ClusterIP      1 => <IP_ADDRESS>:9090
	 4    <IP_ADDRESS>:80       ClusterIP      1 => <IP_ADDRESS>:8080
	 5    <IP_ADDRESS>:31321   NodePort       1 => <IP_ADDRESS>:8080
	 6    <IP_ADDRESS>:31321         NodePort       1 => <IP_ADDRESS>:8080
	 7    <IP_ADDRESS>:53       ClusterIP      1 => <IP_ADDRESS>:53
	                                           2 => <IP_ADDRESS>:53
	 8    <IP_ADDRESS>:3000     ClusterIP      1 => <IP_ADDRESS>:3000
	 12   <IP_ADDRESS>:9080    ClusterIP      1 => <IP_ADDRESS>:9080
	 13   <IP_ADDRESS>:9080    ClusterIP      1 => <IP_ADDRESS>:9080
	                                           2 => <IP_ADDRESS>:9080
	 14   <IP_ADDRESS>:9080    ClusterIP      1 => <IP_ADDRESS>:9080
	 15   <IP_ADDRESS>:9080     ClusterIP      1 => <IP_ADDRESS>:9080

Stderr:

cmd: kubectl exec -n cilium cilium-7t5sr -- cilium endpoint list
Exitcode: 0
Stdout:
 	 ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                                  IPv6   IPv4          STATUS
	            ENFORCEMENT        ENFORCEMENT
	 321        Disabled           Disabled          1          k8s:cilium.io/ci-node=k8s1                                                        ready
	                                                            k8s:cloud.google.com/gke-nodepool=cilium-ci-20
	                                                            k8s:cloud.google.com/gke-os-distribution=cos
	                                                            reserved:host
	 662        Disabled           Disabled          43839      k8s:app=reviews                                                     <IP_ADDRESS>   ready
	                                                            k8s:io.cilium.k8s.namespace.labels.istio-injection=enabled
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.kubernetes.pod.namespace=default
	                                                            k8s:track=stable
	                                                            k8s:version=v1
	                                                            k8s:zgroup=bookinfo
	 1771       Disabled           Disabled          12038      k8s:app=ratings                                                     <IP_ADDRESS>    ready
	                                                            k8s:io.cilium.k8s.namespace.labels.istio-injection=enabled
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.kubernetes.pod.namespace=default
	                                                            k8s:version=v1
	                                                            k8s:zgroup=bookinfo
	 1991       Disabled           Disabled          5847       k8s:app=details                                                     <IP_ADDRESS>   ready
	                                                            k8s:io.cilium.k8s.namespace.labels.istio-injection=enabled
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.kubernetes.pod.namespace=default
	                                                            k8s:track=stable
	                                                            k8s:version=v1
	                                                            k8s:zgroup=bookinfo
	 3101       Disabled           Disabled          9342       k8s:app=productpage                                                 <IP_ADDRESS>    ready
	                                                            k8s:io.cilium.k8s.namespace.labels.istio-injection=enabled
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.kubernetes.pod.namespace=default
	                                                            k8s:track=stable
	                                                            k8s:version=v1
	                                                            k8s:zgroup=bookinfo
	 3964       Disabled           Disabled          4          reserved:health                                                     <IP_ADDRESS>   ready

Stderr:

===================== Exiting AfterFailed =====================
00:33:48 STEP: Running AfterEach for block EntireTestsuite K8sServicesTest
00:33:49 STEP: Running AfterEach for block EntireTestsuite

[[ATTACHMENT|6a65889e_K8sServicesTest_Bookinfo_Demo_Tests_bookinfo_demo.zip]]
00:33:50 STEP: Running AfterAll block for EntireTestsuite K8sServicesTest Bookinfo Demo
00:33:50 STEP: Deleting resource<EMAIL_ADDRESS>00:33:51 STEP: Deleting resource<EMAIL_ADDRESS>00:33:52 STEP: Running AfterAll block for EntireTestsuite K8sServicesTest
00:33:52 STEP: Removing Cilium installation using generated helm manifest

This might somehow be caused by the K8sUpdates test since the GKE builds were green in the backport PR as soon as we removed the unquarantine of K8sUpdates. We might need to quarantine that test again :sweat:

Some initial findings (having run the quarantined K8sUpdates locally, followed by K8sIstioTest):
The reason why DNS lookups for Kubernetes services is not working, is because kube-dns is unable to connect to the K8s API server (normal DNS requests are served just fine):
$ kubectl logs -n kube-system kube-dns-7c976ddbdb-h7n6n -c kubedns
1125 10:55:52.262228       1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:193: Failed to list *v1.Service: Get https://<IP_ADDRESS>:443/api/v1/services?resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout
E1125 10:55:52.263123       1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:190: Failed to list *v1.Endpoints: Get https://<IP_ADDRESS>:443/api/v1/endpoints?resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout

An interesting observation here is that while the kube-dns pods are present in the CiliumEndpoints CRD, they are not considered managed endpoints by the cilium agent hosting them:
kubectl get cep -n kube-system
NAME                                                       ENDPOINT ID   IDENTITY ID   INGRESS ENFORCEMENT   EGRESS ENFORCEMENT   VISIBILITY POLICY   ENDPOINT STATE   IPV4          IPV6
event-exporter-gke-8489df9489-crshm                        2403          13780                                                                        ready            <IP_ADDRESS>
fluentd-gke-scaler-cd4d654d7-zttd5                         2805          53097                                                                        ready            <IP_ADDRESS>
kube-dns-7c976ddbdb-h7n6n                                  1793          5861                                                                         ready            <IP_ADDRESS>
kube-dns-7c976ddbdb-ksghm                                  2510          5861                                                                         ready            <IP_ADDRESS>
kube-dns-autoscaler-645f7d66cf-lcxcz                       1523          40043                                                                        ready            <IP_ADDRESS>
l7-default-backend-678889f899-w7kh8                        1063          2248                                                                         ready            <IP_ADDRESS>
metrics-server-v0.3.6-64655c969-bdcjn                      2121          36505                                                                        ready            <IP_ADDRESS>
stackdriver-metadata-agent-cluster-level-9dccb99b4-v5qh4   843           785                                                                          ready            <IP_ADDRESS>

$ kubectl get pod -n kube-system kube-dns-7c976ddbdb-h7n6n -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE                                                  NOMINATED NODE   READINESS GATES
kube-dns-7c976ddbdb-h7n6n   4/4     Running   0          20h   <IP_ADDRESS>   gke-sebastian-ci-force-2-default-pool-5077a7b5-5whr   <none>           <none>
$ kubectl get pod -n cilium -l k8s-app=cilium -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP              NODE                                                  NOMINATED NODE   READINESS GATES
cilium-cq2kb   1/1     Running   0          20h   <IP_ADDRESS>   gke-sebastian-ci-force-2-default-pool-5077a7b5-xh88   <none>           <none>
cilium-n68zj   1/1     Running   0          20h   <IP_ADDRESS>   gke-sebastian-ci-force-2-default-pool-5077a7b5-6zcs   <none>           <none>
cilium-qslrp   1/1     Running   0          20h   <IP_ADDRESS>   gke-sebastian-ci-force-2-default-pool-5077a7b5-5whr   <none>           <none>
$ kubectl exec -n cilium -ti cilium-qslrp -- cilium endpoint list
ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                                  IPv6   IPv4          STATUS
           ENFORCEMENT        ENFORCEMENT
174        Disabled           Disabled          4          reserved:health                                                     <IP_ADDRESS>   ready
528        Disabled           Disabled          1          k8s:cilium.io/ci-node=k8s1                                                        ready
                                                           k8s:cloud.google.com/gke-nodepool=default-pool
                                                           k8s:cloud.google.com/gke-os-distribution=cos
                                                           reserved:host

Some additional observations and theories:
The CEP garbage collector will not remove an entry if a pod with the same name still exists (source). It seems fair to assume that if there is a pod for a given CEP, that the entry is valid, because Cilium will restore any already existing endpoints from the bpf maps on the host.
However, in the case of K8sUpdates, it seems that we are explicitly cleaning up the BPF state between updates (source). The CEPs on the other hand seem to be kept (?). This leads to the above symptom where the CEP and pod exists, but the actual datapath endpoint does not.
Being an unmanaged pod on GKE is known to cause connectivity issues. This is why we restart all unmanaged pods on the GKE test suite (source). The RestartUnmanagedPodsInNamespace does not work here, because the kube-dns pods have existing CEPs, they are not restarted here, leading to the above connectivity issues.
It seems like one way to fix this would be to make sure to clean up the CEPs as well if we do ciliumCleanup in CI, assuming the CEP GC behavior is intended.

The cleanup in K8sUpdates test is intended to reset the cluster to a 'fresh' deployment of the old version of Cilium prior to performing the upgrade testing, so I think it would be reasonable to clear out all of the CEPs in that specific case.

Still happening here: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.13-net-next/387/testReport/junit/Suite-k8s-1/13/K8sServicesTest_Bookinfo_Demo_Tests_bookinfo_demo/, re-opening to encourage further reporting.

Still happening here: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.13-net-next/387/testReport/junit/Suite-k8s-1/13/K8sServicesTest_Bookinfo_Demo_Tests_bookinfo_demo/, re-opening to encourage further reporting.

The new failure did not happen on GKE, so it probably has a different root cause then the previous issue (which was very GKE specific). I'm unassigning myself for now from this.

The new failure did not happen on GKE, so it probably has a different root cause then the previous issue (which was very GKE specific). I'm unassigning myself for now from this.

Given title of this issue mentions GKE, I think we should track the failure you're seeing @jrajahalme in a separate issue. As Sebastian mentioned, a fix for the GKE specific variant has been made.

Given title of this issue mentions GKE, I think we should track the failure you're seeing @jrajahalme in a separate issue. As Sebastian mentioned, a fix for the GKE specific variant has been made.

Given title of this issue mentions GKE, I think we should track the failure you're seeing @jrajahalme in a separate issue. As Sebastian mentioned, a fix for the GKE specific variant has been made.

Hit the same failure as reported by @jrajahalme in https://github.com/cilium/cilium/issues/13833#issuecomment-757166485, opened #14598 to track the failure.

Given title of this issue mentions GKE, I think we should track the failure you're seeing @jrajahalme in a separate issue. As Sebastian mentioned, a fix for the GKE specific variant has been made.

Hit the same failure as reported by @jrajahalme in https://github.com/cilium/cilium/issues/13833#issuecomment-757166485, opened #14598 to track the failure.


Remove boto3_session reference from athena test and opensearch utils module

Feature or Bugfix

Bugfix

Detail
Even though they both pertain to boto3 sessions, these two minor changes are unrelated:

Change 1: OpenSearch utils module has boto3.Session as a default. Changed to None instead like in the rest of the codebase
Change 2: test_athena_query_cancelled is consistently failing in CB. My suspicion is that it's due to the unnecessary use of a boto3.session

Relates

#1428

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 10a3d50567266e5aec15d711d09694a75dd38145
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 6290bd3a4676572793271e10e634665e50122831
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 32b77248f528810cbfcaa20592ea4c08f521ae69
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Security/Threat protection: password length values

Description:
As requested by Program Manager Robert Durff (@MSRobertD) in issue ticket #6856 (Bug: Password length value range is inaccurate.), the upper value for the supported values for password length should be 20 instead of only 14, verified in preliminary field testing of the GPO Password Policy, described on this page.
The actual upper limit may very well be higher, but 20 is a reasonable value to be used for now, until someone documents the need for higher accuracy in the documentation of this value for the GPO Password Policy.
Changes proposed:

Replace 14 with 20 in both occurrences of 14 as the upper value
Convert Note text in line 83 to a MarkDown Note blob (MS codestyle)
Whitespace adjustments:

Normalize bullet point list spacing to 1 (codestyle) (3 lines)
Remove redundant end-of-line spacing (8 lines)

Ticket closure or reference:
Closes #6856

#sign-off

Thank you for the nice feedback. Feel free to use the [Review changes] > (●) Approve > [Submit review] if you like, to put your "stamp of approval" on it.


[TFOP-227] update react, add jest/enzyme/simple test

Good thought. I'll add the circle check to this PR. I think it goes better here.


Ember.js Uncaught TypeError: Cannot set property 'fillStyle' of undefined

Hey, so I'm trying to use WaveSurfer within my Ember.js project with no prevail(I doubt Ember is causing these issues).
I imported the latest version of wavesurfer.js through Bower, and then used this exact code in one of my templates:

Now when I try to see if it works, my console errors saying Uncaught TypeError: Cannot set property 'fillStyle' of undefined.
Here's what line in wavesurfer.js it's erroring at:
    setFillStyles: function (entry) {
        entry.waveCtx.fillStyle = this.params.waveColor; <--- HERE
        if (this.hasProgressCanvas) {
            entry.progressCtx.fillStyle = this.params.progressColor;
        }
    },

can you try to reproduce it without ember?

@thijstriemstra Actually I tested it out about 30min ago and got it to work. I wonder why it doesn't work within Ember?

I'm not familiar with ember.js but if you figure it out let us know here.

@thijstriemstra a user on StackOverflow sent me this discussion and I seem to be in the same boat somehow. I rolled back from 1.3.4 to 1.2.8 and it's working now. Any suggestions as to how I could get it to where I can be using the current versions?

@thijstriemstra I have the same problem, but I am not using Ember. Investigating...

Actually I think there was an issue a few months back somebody had while using ember. I think the cause was incorrect for (entry in this.canvases) (this.canvases being an array and not an object) https://github.com/katspaugh/wavesurfer.js/pull/961  and https://github.com/katspaugh/wavesurfer.js/issues/947 – Maybe this is related somehow.

Thank you. This was exactly the problem!

Hey, I just tried out the 2.0 beta and it's working great! Good work!


(BKR-1264) Ensure vm.hostname is legal

Some of the newer beaker-hosgenerator definitions contain underscores
which are illegal as hostnames, preventing vagrant configuring and
bringing up a machine (e.g. windows2012r2_ja-64-1). vmpooler for example
doesn't have a problem with this as the the actual hostname is obtained
from the vmpooler API, whereas beaker-vagrant re-uses the hostname
directly.
Translate any underscores in host.name to hyphens to ensure a legal
hostname.

Can one of the admins verify this patch?

I've setup a test environment for this as follows

Created facter branch with modified Gemfile to add beaker-vagrant pointing here.
Temporarily modified the win-2012r2-core & win-2016-core vagrant acceptance tests to use the modified vagrant branch.
The builds ran ok, referenced the updated beaker-vagrant branch and was able to bring the VM up correctly.
Also verified that the hostname was translated in the Vagrantfile to replace underscores with hyphens.

Bundler Gem loading modified beaker-vagrant
08:03:30 Installing beaker-hiera 0.1.1
08:03:30 Using beaker-vagrant 0.1.1 from https://github.com/jcoconnor/beaker-vagrant.git (at BKR-1264-wincore-vagrant@fc60498)
08:03:30 Fetching beaker-vmpooler 1.1.0

Log, showing Hostname with underscores, and machine coming up with name fixed up.
08:03:40 + cat hosts.yaml
08:03:40 ---
08:03:40 HOSTS:
08:03:40   windows2016_core-64-1:
08:03:40     pe_dir:
08:03:40     pe_ver:
08:03:40     pe_upgrade_dir:
08:03:40     pe_upgrade_ver:
08:03:40     platform: windows-2016-64
08:03:40     packaging_platform: windows-2012-x64
08:03:40     ruby_arch: x64
08:03:40     hypervisor: vagrant
08:03:40     box_url: file:///srv/packer/output/output-win-2016-core-x86_64-virtualbox-vagrant.cygwin/win-2016-core-x86_64-virtualbox-vagrant.cygwin.box
08:03:40     user: vagrant
08:03:40     password: vagrant
08:03:40     box: winpacker/windows2016_core-64
08:03:40     roles:
08:03:40     - agent
08:03:40 CONFIG:
08:03:40   nfs_server: none
08:03:40   consoleport: 443
08:03:40 + echo 'Run beaker against the host.yaml file'
08:03:40 Run beaker against the host.yaml file
08:03:40 + GEM_SOURCE=http://rubygems.delivery.puppetlabs.net/
08:03:40 + bundle exec rake ci:test:aio BEAKER_HOSTS=hosts.yaml SUITE_VERSION=<IP_ADDRESS>3.g94993f4 SHA=94993f4462a1c9b29b290420dc3734407ef49035
08:03:40 beaker --options-file merged_options.rb --hosts=hosts.yaml
08:03:40 ./config/aio/options.rb
08:03:40 ./local_options.rb
08:03:40 No options file found at /var/lib/jenkins/workspace/imaging_win-2016-core_x86_64_virtualbox_vagrant.cygwin_acceptance_packer/acceptance/facter/acceptance/local_options.rb
08:03:41 Hypervisor for windows2016_core-64-1 is vagrant
08:03:41 Beaker::Hypervisor, found some vagrant boxes to create
08:03:41 created Vagrantfile for VagrantHost windows2016-core-64-1
08:03:45 Bringing machine 'windows2016-core-64-1' up with 'virtualbox' provider...
08:03:46 ==> windows2016-core-64-1: Box 'winpacker/windows2016_core-64' could not be found. Attempting to find and install...
08:03:46     windows2016-core-64-1: Box Provider: virtualbox
08:03:46     windows2016-core-64-1: Box Version: >= 0
08:03:47 ==> windows2016-core-64-1: Box file was not detected as metadata.  This may take a few minutes...
08:07:54     windows2016-core-64-1: WinRM address: <IP_ADDRESS>:5985
08:07:54     windows2016-core-64-1: WinRM username: vagrant
08:07:54     windows2016-core-64-1: WinRM execution_time_limit: PT2H
08:07:54     windows2016-core-64-1: WinRM transport: negotiate
08:09:00 ==> windows2016-core-64-1: Machine booted and ready!
08:09:00 ==> windows2016-core-64-1: Checking for guest additions in VM...
08:09:00 ==> windows2016-core-64-1: Setting hostname...
08:10:46 ==> windows2016-core-64-1: Configuring and enabling network interfaces...
08:10:59 ==> windows2016-core-64-1: Mounting shared folders...

@jcoconnor the code looks fine here, but would you please add a spec test so that we don't break your work in the future? Once that's done, we should be able to push this through testing, merge, & release it. Thank you.

@kevpl I've added spec test that checks the translation is happening.
Is this OK ?

👍  @puppetlabs-jenkins test this please


ibus predict window is shown at the previous cursor position

What steps will reproduce the problem?
1. Open a html file or access a page which has textarea in Firefox(a sample
html file is attached).

2. Type the following keys to input "今日の天気は晴れ" in the textarea.
"kyouno<space>tenkiha<space>hare"

3. See the position of ibus predict window for "hare".

What is the expected output?
ibus predict windows is shown at the position of "hare".

What do you see instead?
ibus predict window is shown at the position of "tenkiha".
See attached screenshot.

What version of the product are you using? On what operating system?

Ubuntu 14.10 Utopic Unicorn (development branch)
ibus-mozc:
  Installed: 1.15.1857.102-1
firefox:
  Installed: 31.0~b6+build2-0ubuntu1

Please provide any additional information below.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 7 Aug 2014 at 12:56

Blocked on: #287

Attachments:

firefox-textarea.png
textarea.html

I confirmed that 9fbcdd5e27cf26ff16d72bd2d92f269334912ede does fix the case of gedit but the original issue in Firefox persists as of Firefox Nightly 2015-08-31.  Probably there were two different issues and the firefox-specific one cannot be fixed in ibus-mozc side.  I've just reported as Mozilla Bug 1200506 for firefox-specific one.


Incorrect information on auto upgrade status

Hi
Please fix the last 2 bullets on the page to show that auto upgrade for clusters and node images are fully GA now.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 43da9bdf-a3d3-a65b-b555-60dcc5ac2c55
Version Independent ID: 9913c705-aeb7-e154-4fdf-164ff1e7ff99
Content: AKS Day-2 - Patch and upgrade guidance - Azure Architecture Center
Content Source: docs/operator-guides/aks/aks-upgrade-practices.md
Service: architecture-center
Sub-service: reference-architecture
GitHub Login: @rishabhsaha
Microsoft Alias: pnp

@carmodyquinnms Thanks for your comment. We will review the issue and get back to you shortly.

This update was made by @PixelRobots & @rishabhsaha and should be going live today yet - unless the publication process gets hung up for some reason (in that case it will be tomorrow). Thanks @carmodyquinnms.


Consider switching to controller-runtime

To simplify logic of setting the controller up and various reconcilers, I think it would be possible to switch for controller-runtime and to set up reconcilers for both Node and Service objects. It would take care of caching etc and should make CCM easier to test I think.

Since we simplified them all to use the proper calls from k8s.io/cloud-provider, this is not necessary.


False positive: terraform ec2_instance_has_public_ip

Found a bug? You're welcome to

Please make sure to:

Describe in details what the problem is
Attach a log file with relevant data preferably in DEBUG level (--log-level=DEBUG)
Attach the scanned sample files, anonymize the data if the original file cannot be provided
When attaching files to the issue make sure they are properly formatted

When an ec2 instance is defined with an explicit network interface, you cannot specify the associate_public_ip_address parameter for the aws_instance.  You get
Error: Conflicting configuration arguments - "network_interface": conflicts with associate_public_ip_address

In my case, the aws_network_interface is provisioned in a private subnet, hence the ec2 instance will not have a public IP address.  But the rego isn't able to make that determination.
Expected Behavior
No error
Actual Behavior
EC2 Instance Has Public IP, Severity: HIGH, Results: 1
Description: EC2 Instance should not have a public IP address.
Platform: Terraform
	[1]: main.tf:59
		058:
		059: resource "aws_instance" "this" {
		060:   ami                  = data.aws_ami.amazon-linux.id

Steps to Reproduce the Problem
Provision an aws_instance using an explicit aws_network_interface.  Simplified version below.
resource "aws_network_interface" "this" {
  subnet_id       = var.private_subnet_id
  security_groups = [aws_security_group.this.id]
}

resource "aws_security_group" "this" {
  name        = "example"
  description = "Example Security Group"
  ...
}

resource "aws_instance" "this" {
  ami                  = data.aws_ami.amazon-linux.id
  instance_type        = "t3a.micro"
  availability_zone    = var.availability_zone

  network_interface {
    network_interface_id = aws_network_interface.this.id
    device_index         = 0
  }
  ...
}

Run kics like this:
kics scan -p "." -t "Terraform" --fail-on "high"

Specifications
N/A

Hi @jpriebe, hope you are doing great!
I am glad to inform you that PR #5720 was created to solve this issue.

Thanks, @cxMiguelSilva - this will be very helpful!