text:
CI builds are broken due to Semaphore issue

KVM: entry failed, hardware error 0x0
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000663
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=00 66 89 d8 66 e8 0c ad ff ff 66 83 c4 0c 66 5b 66 5e 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
qemu: terminating on signal 15 from pid 2634 (timeout)

xref https://github.com/newtools/ebpf/issues/67

I was told by Semaphore support that they plan to deploy a fix in the coming days.

Seems to be fixed.

Seems to be fixed.

Unfortunately, the bug appears to be back. See recent builds.

I plan to look for and test an alternative.

@schu Verdict?

We resorted to GitHub actions for the time being. (https://github.com/iovisor/gobpf/commit/493dbd89a11293255489e5eb11f27e1468de47b1)

authors: jnach schu

repo: iovisor/gobpf


text:
Is a license file not used anymore with the IP2Location?

Before I used an old IP2Location component which required a license file as well as a database file.
It looks like a license file is not needed anymore.
Please confirm if so.

Yes, a license file is no longer needed.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Python module 'ipctk' has no attribute 'Collision'

Describe the bug
Trying to call the Collisions constructor in Python raises an AttributeError module 'ipctk' has no attribute 'Collision'.
To Reproduce
Call the Collisions constructor, ie. collisions = ipctk.Collisions().
Environment (please complete the following information):

OS: Debian Sid
Version: IPCTK 1.2
Python version: Python 3.8.19

Collisions is called CollisionConstraints in v1.2. I think you might be looking at the latest documentation while using version 1.2. Here are the docs to v1.2: https://ipctk.xyz/v1.2.0/tutorial/getting_started.html.

That's correct - thanks for pointing me in the right direction :)

authors: elkalt zfergus

repo: ipc-sim/ipc-toolkit


text:
Meaningful error in idm-client when we are unable to reach wallet

Description
Instead of showing the standard promised error, show something like: we are unable to reach the wallet, please make sure it is open
Acceptance Criteria

[x] The wallet has now a meaningful error

Done in https://github.com/ipfs-shipyard/js-idm-bridge-postmsg/commit/e176169bda23df6f5e1824982eabff4dfb759204

authors: PedroMiguelSS satazor

repo: ipfs-shipyard/pm-idm


text:
fix link to JS contrib guidelines

Link to JS contribution guidelines was pointing to a file that doesn't exist

Thanks.

source: gharchive/pull-request

authors: RichardLitt jafow

repo: ipfs/community


text:
feat(mv3): adding dynamicNetRequest rule reconciliation logic

Blocked by #1181

https://github.com/ipfs/ipfs-companion/pull/1181 is merged now, is this still blocked, or just parked for now?

authors: SgtPooki whizzzkid

repo: ipfs/ipfs-companion


text:
Fake credit card API

API that returns as follows

cardholder name
card type
card number
card expiration month (01)
card expiration year (22)

Assign to me. I've done the PR for this feature https://github.com/iphadey/api-hug/pull/5
Thanks

thanks mate!

authors: iphadey metallurgical

repo: iphadey/api-hug


text:
got some error when run crow

Hi everyone, I have tried to run some examples of code using crow but I faced a problem so I need your help.
my code
#include "crow_all.h"

int main()
{
    crow::SimpleApp app;

    CROW_ROUTE(app, "/")([](){
        return "Hello world";
    });

    app.port(18080).multithreaded().run();
}

CMakelist.txt
cmake_minimum_required(VERSION 3.15)
project(untitled)

set(CMAKE_CXX_STANDARD 11)

add_executable(untitled main.cpp)

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread -lboost_system")

Error:
CMakeFiles/untitled.dir/main.cpp.o: In function `__static_initialization_and_destruction_0(int, int)':
/usr/include/boost/system/error_code.hpp:206: undefined reference to `boost::system::generic_category()'
/usr/include/boost/system/error_code.hpp:208: undefined reference to `boost::system::generic_category()'
/usr/include/boost/system/error_code.hpp:210: undefined reference to `boost::system::system_category()'
CMakeFiles/untitled.dir/main.cpp.o: In function `boost::system::error_code::error_code()':
/usr/include/boost/system/error_code.hpp:439: undefined reference to `boost::system::system_category()'
CMakeFiles/untitled.dir/main.cpp.o: In function `boost::system::error_category::std_category::equivalent(int, std::error_condition const&) const':
/usr/include/boost/system/error_code.hpp:656: undefined reference to `boost::system::generic_category()'
/usr/include/boost/system/error_code.hpp:659: undefined reference to `boost::system::generic_category()'
CMakeFiles/untitled.dir/main.cpp.o: In function `boost::system::error_category::std_category::equivalent(std::error_code const&, int) const':
/usr/include/boost/system/error_code.hpp:686: undefined reference to `boost::system::generic_category()'
/usr/include/boost/system/error_code.hpp:689: undefined reference to `boost::system::generic_category()'
/usr/include/boost/system/error_code.hpp:701: undefined reference to `boost::system::generic_category()'
CMakeFiles/untitled.dir/main.cpp.o: In function `boost::asio::error::get_system_category()':
/usr/include/boost/asio/error.hpp:230: undefined reference to `boost::system::system_category()'
collect2: error: ld returned 1 exit status

Did you installed boost in your system?

Did you installed boost in your system?

@mrozigor yeppp, i have installed boost

Maybe try to use find_package( Boost 1.52 COMPONENTS system thread REQUIRED ) in your CMakeLists.txt file as in project's CMakeLists.txt file?

Maybe try to use find_package( Boost 1.52 COMPONENTS system thread REQUIRED ) in your CMakeLists.txt file as in project's CMakeLists.txt file?

I hve tried and it cannot find  COMPONENTS system thread REQUIRED!

So it means that you don't have installed boost-1.52. Can you give me some output from your package manager with boost version?

@mrozigor  It said "Could NOT find Boost (missing: filesystem)", Can you help me to solve that problem?

It looks like problem with boost installation. Or maybe path to library isn't set. Try to find the solution through goole.

I'm facing the same issue but this command "find_package( Boost 1.52 COMPONENTS system thread REQUIRED )" was successfully able to find boost. How do I successfully run the entire code?

Maybe try https://stackoverflow.com/a/27696770 ?

authors: baopanda mrozigor shitijkarsolia

repo: ipkn/crow

license_source: bigquery


text:
🛑 CounterApi (brochure) is down

In 25a3648, CounterApi (brochure) (https://counterapi.com/) was down:

HTTP code: 502
Response time: 144 ms

Resolved: CounterApi (brochure) is back up in 49c2e7a after 6 minutes.

repo: iplanwebsites/up


text:
🛑 NowBoarding (tokyo) is down

In 4bbf989, NowBoarding (tokyo) (https://tokyo.nowboarding.club/) was down:

HTTP code: 502
Response time: 2236 ms

Resolved: NowBoarding (tokyo) is back up in 96709f4 after 23 minutes.


text:
🛑 CounterApi (brochure) is down

In 8ee3917, CounterApi (brochure) (https://counterapi.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CounterApi (brochure) is back up in f894022.


text:
🛑 Lovely (img) is down

In b8d336f, Lovely (img) (https://img.lovely.link/v1/invitation/profile?title=title&text1=text1&text2=text2&text3=text3&avatar=https%3A%2F%2Frandomuser.me%2Fapi%2Fportraits%2Fwomen%2F67.jpg&rating5=0) was down:

HTTP code: 504
Response time: 11328 ms

Resolved: Lovely (img) is back up in 71eae0f.


text:
Downloading Schedule directly from iMaalum using student credentials

I've been trying to figure out how to download the confirmation slip directly from iMaalum's website using POST requests. It seems I need to find out how to do GET request with cookies.

I did it using Go to login to the website and get the login cookies. However, when trying to get a specific file, it returns the main webpage.
So, in order to succeed in login, send a GET request to the server to get the first cookie, and send a POST request with credentials to get the second cookie and successfully login to iMaalum. The remaining problem is requesting the schedule file

resp_first,_ := client.Get("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome")
	client.Jar.SetCookies(urlObj,resp_first.Cookies())
	resp,_ := client.PostForm("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome",formVal)
	// client.Jar.SetCookies(urlObj,resp.Cookies())
	resp_get,_:=client.Get("https://imaluum.iium.edu.my/MyAcademic/resultprint?")

It's working now. You just have to translate the code to Dart and after that you can get the files directly from iMaalum
urlObj,_ := url.Parse("https://imaluum.iium.edu.my/") 	resp_first,_ := client.Get("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome") 	client.Jar.SetCookies(urlObj,resp_first.Cookies()) 	cookies1 := resp_first.Cookies() 	resp,_ := client.PostForm("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome",formVal) 	newCook:=append(cookies1, resp.Cookies()...) 	client.Jar.SetCookies(urlObj,newCook) 	resp_get,_ :=client.Get("https://imaluum.iium.edu.my/confirmationslip?ses=2022/2023&sem=1")

Mah mann, I tried them just now and it just works! Porting this into Dart...

Hey @PlashSpeed-Aiman. I'm working on porting the Dart code but stuck a bit, wondering if you could shed some light ahha
Go
In the Go code, I tried to inspect the outgoing request to understand the cookies etc.
So for first GET request.
	resp_first, _ := client.Get("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome")

	fmt.Println("resp_first Header")
	fmt.Println(resp_first.Header)
	fmt.Println()

Output:
map[Cache-Control:[no-cache, no-store, max-age=0, must-revalidate] Content-Language:[en] Content-Type:[text/html;charset=UTF-8] Date:[Sun, 25 Dec 2022 05:06:16 GMT] Expires:[0] Pragma:[no-cache] Server:[Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_nss/1.0.14 NSS/3.28.4 PHP/5.4.16] Set-Cookie:[SESSION=19057333-0ec9-4dc4-a08f-d030e41cab53;path=/cas/;Secure;HttpOnly YpN9wASukHaMGkYA=v1cyFLgw__wKC; Expires=Sun, 25-Dec-2022 07:06:16 GMT; Path=/; Secure] Strict-Transport-Security:[max-age=15768000 ; includeSubDomains] Vary:[Accept-encoding] X-Content-Type-Options:[nosniff] X-Frame-Options:[DENY] X-Xss-Protection:[1; mode=block]]

For second request (POST)
	client.Jar.SetCookies(urlObj, resp_first.Cookies())
	cookies1 := resp_first.Cookies()
	resp, _ := client.PostForm("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome", formVal)
	fmt.Println("resp Request Header")
	fmt.Println(resp.Request.Header)

Output:
resp Request Header
map[Content-Type:[application/x-www-form-urlencoded] Cookie:[YpN9wASukHaMGkYA=v1cyFLgw__wKC; MOD_AUTH_CAS=344c7f76cf41a9eefac3ef03607da9d0] Referer:[https://imaluum.iium.edu.my/home?ticket=ST-5718104-9NtiIQxqQ4wVngG6WSd--OGJoxo-cas2]]

So, I wonder here does MOD_AUTH_CAS come from in the second request? It doesn't appear in the first cookie response.
Dart
In Dart, I got 500 error while POST-ing the second request

void login(String username, String password) async {
    var dio = Dio();
    var cookieJar = CookieJar();
    await cookieJar.deleteAll();
    dio.interceptors.add(CookieManager(cookieJar));

    var imaluumUri = Uri.parse('https://imaluum.iium.edu.my/');
    var casUrl =
        'https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome';
    //Get first cookies
    var res1 = await dio.get(casUrl);

    var parsedCookies = res1.headers['set-cookie']?.map((e) {
      var cookie = Cookie.fromSetCookieValue(e);
      return cookie;
    }).toList();

    print('First response cookies:');
    print(parsedCookies);

    // save cookies
    await cookieJar.saveFromResponse(imaluumUri, parsedCookies!);

    // print(await cookieJar.loadForRequest(imaluumUri));

    var formVal = {
      'username': username,
      'password': password,
      'execution': 'e1s1',
      '_eventId': 'submit',
      'geolocation': '',
    };

    FormData formData = FormData.fromMap(formVal);
    // print(formData.fields);
    Response? resAuth;

    // second request with the cookie
    try {
      resAuth = await dio.post(
        'https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome',
        data: formData,
        options: Options(contentType: Headers.formUrlEncodedContentType),
      );
    } on DioError catch (e) {
      print('Second request');
      print(e.requestOptions.headers);
    }

    print(resAuth);
    // print(await cookieJar.loadForRequest(imaluumUri));

    return;
}

Output:
First response cookies:
[SESSION=30f87fbc-76de-462b-942b-c0948a09c7ff; Path=/cas/; Secure; HttpOnly, YpN9wASukHaMGkYA=v1cyFLgw__wKC; Expires=Sun, 25 Dec 2022 07:14:38 GMT; Path=/; Secure]
Second request
{content-type: multipart/form-data; boundary=--dio-boundary-3844012906, cookie: SESSION=30f87fbc-76de-462b-942b-c0948a09c7ff; YpN9wASukHaMGkYA=v1cyFLgw__wKC, content-length: 550}

I believe because it doesn't send along with the MOD_AUTH_CAS cookie

Try changing  await cookieJar.saveFromResponse(imaluumUri, parsedCookies!); to await cookieJar.saveFromResponse(casUrl, parsedCookies!); and save all cookies from POST request because in the Go implementation I saved both cookies from GET and POST. Those cookies will be used when downloading files etc

I think it's better to use http or dart http libraries compared to DIO. I read in some places that DIO doesn't work most of the time.

I see. Yeah, that might be the case. Thank you.

Hey @PlashSpeed-Aiman. I'm working on porting the Dart code but stuck a bit, wondering if you could shed some light ahha
Go
In the Go code, I tried to inspect the outgoing request to understand the cookies etc.
So for first GET request.
	resp_first, _ := client.Get("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome")

	fmt.Println("resp_first Header")
	fmt.Println(resp_first.Header)
	fmt.Println()

Output:
map[Cache-Control:[no-cache, no-store, max-age=0, must-revalidate] Content-Language:[en] Content-Type:[text/html;charset=UTF-8] Date:[Sun, 25 Dec 2022 05:06:16 GMT] Expires:[0] Pragma:[no-cache] Server:[Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_nss/1.0.14 NSS/3.28.4 PHP/5.4.16] Set-Cookie:[SESSION=19057333-0ec9-4dc4-a08f-d030e41cab53;path=/cas/;Secure;HttpOnly YpN9wASukHaMGkYA=v1cyFLgw__wKC; Expires=Sun, 25-Dec-2022 07:06:16 GMT; Path=/; Secure] Strict-Transport-Security:[max-age=15768000 ; includeSubDomains] Vary:[Accept-encoding] X-Content-Type-Options:[nosniff] X-Frame-Options:[DENY] X-Xss-Protection:[1; mode=block]]

For second request (POST)
	client.Jar.SetCookies(urlObj, resp_first.Cookies())
	cookies1 := resp_first.Cookies()
	resp, _ := client.PostForm("https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome", formVal)
	fmt.Println("resp Request Header")
	fmt.Println(resp.Request.Header)

Output:
resp Request Header
map[Content-Type:[application/x-www-form-urlencoded] Cookie:[YpN9wASukHaMGkYA=v1cyFLgw__wKC; MOD_AUTH_CAS=344c7f76cf41a9eefac3ef03607da9d0] Referer:[https://imaluum.iium.edu.my/home?ticket=ST-5718104-9NtiIQxqQ4wVngG6WSd--OGJoxo-cas2]]

So, I wonder here does MOD_AUTH_CAS come from in the second request? It doesn't appear in the first cookie response.
Dart
In Dart, I got 500 error while POST-ing the second request

void login(String username, String password) async {
    var dio = Dio();
    var cookieJar = CookieJar();
    await cookieJar.deleteAll();
    dio.interceptors.add(CookieManager(cookieJar));

    var imaluumUri = Uri.parse('https://imaluum.iium.edu.my/');
    var casUrl =
        'https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome';
    //Get first cookies
    var res1 = await dio.get(casUrl);

    var parsedCookies = res1.headers['set-cookie']?.map((e) {
      var cookie = Cookie.fromSetCookieValue(e);
      return cookie;
    }).toList();

    print('First response cookies:');
    print(parsedCookies);

    // save cookies
    await cookieJar.saveFromResponse(imaluumUri, parsedCookies!);

    // print(await cookieJar.loadForRequest(imaluumUri));

    var formVal = {
      'username': username,
      'password': password,
      'execution': 'e1s1',
      '_eventId': 'submit',
      'geolocation': '',
    };

    FormData formData = FormData.fromMap(formVal);
    // print(formData.fields);
    Response? resAuth;

    // second request with the cookie
    try {
      resAuth = await dio.post(
        'https://cas.iium.edu.my:8448/cas/login?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome?service=https%3a%2f%2fimaluum.iium.edu.my%2fhome',
        data: formData,
        options: Options(contentType: Headers.formUrlEncodedContentType),
      );
    } on DioError catch (e) {
      print('Second request');
      print(e.requestOptions.headers);
    }

    print(resAuth);
    // print(await cookieJar.loadForRequest(imaluumUri));

    return;
}

Output:
First response cookies:
[SESSION=30f87fbc-76de-462b-942b-c0948a09c7ff; Path=/cas/; Secure; HttpOnly, YpN9wASukHaMGkYA=v1cyFLgw__wKC; Expires=Sun, 25 Dec 2022 07:14:38 GMT; Path=/; Secure]
Second request
{content-type: multipart/form-data; boundary=--dio-boundary-3844012906, cookie: SESSION=30f87fbc-76de-462b-942b-c0948a09c7ff; YpN9wASukHaMGkYA=v1cyFLgw__wKC, content-length: 550}

I believe because it doesn't send along with the MOD_AUTH_CAS cookie

I finally managed to solve the MOD_AUTH_CAS problem. The following PR will be submitted later.
Apparently, the CAS server will return the MOD_AUTH_CAS cookie inside the 302 HTTP response after executing a GET request on the url returned by the server after a successful login attempt but somehow, Dart's http library skipped that cookie. Consequently, i-Maluum redirects any subsequent requests to the CAS page. By setting HttpClientRequest.followRedirects = false, we can easily get the MOD_AUTH_CAS cookie.

However, I believe the current implementation of parsing schedules directly from i-Maluum using WebView is much more friendly than requiring users to enter their matric number and password into our text fields. Users will get a sense of safety and trust as they used to log in into i-Maluum

Apparently, the CAS server will return the MOD_AUTH_CAS cookie inside the 302 HTTP response after executing a GET request on the url returned by the server after a successful login attempt but somehow, Dart's http library skipped that cookie. Consequently, i-Maluum redirects any subsequent requests to the CAS page. By setting HttpClientRequest.followRedirects = false, we can easily get the MOD_AUTH_CAS cookie.

Ahh I see. Thank you Elyas.

I believe the current implementation of parsing schedules directly from i-Maluum using WebView is much more friendly than requiring users to enter their matric number and password into our text fields.

Agreed 💯 . We'll keep it as default. Perhaps, the method we've discussed here can be useful on web/windows because WebView is not supported there.

authors: ElyasAsmad PlashSpeed-Aiman iqfareez


text:
Detach splat constants used as outs operands for LinalgExt ops.

Having a splat constant as an outs operand results in stack
allocations. The canonical way to represent these is through use of
linalg.fill operations. These get tiled + fused + bufferized without
having to allocate any stack allocations. This is probably needed for
all LinalgOps as well, but for now just limit these to
LinalgExtOps.
Issue #9896

Heads up that this will skew the memory consumption numbers quite a bit until we can fuse it again - unless they end up in-place after dispatch region formation? Better to work than not but something to note if we see the regressions appear (assuming anyone is watching :).
(here it's an extra 13.5MB if it doesn't get done in-place)

I think it should end up in-place....

At least it improves compilation time! (Actually it shouldnt. I think that is basically noise)

hah! yeah I was noticing the ~20% noise on other PRs too - makes the compilation time stats not so useful unless it catches something multiple times off (which is still useful, but not something that can be used for hill climbing).

authors: MaheshRavishankar benvanik

repo: iree-org/iree


text:
Web demo cannot be deployed

In Semi.Avalonia.Demo.Web, it can work through the dotnet run command, but it will cause error when I publish and deploy the demo.

Uncaught Error: AggregateException_ctor_DefaultMessage (No precompiled XAML found for avares://Semi.Avalonia/Locale/zh-cn.axaml (baseUri: ), make sure to specify x:Class and include your XAML file as AvaloniaResource)

If I use this StyleInclude in App.axaml:

<StyleInclude Source="avares://Semi.Avalonia/Themes/Index.axaml"

It will cause another similar error:

Uncaught Error: AggregateException_ctor_DefaultMessage (No precompiled XAML found for avares://Semi.Avalonia/Themes/Light/_index.axaml (baseUri: avares://Semi.Avalonia/Themes/Index.axaml), make sure to specify x:Class and include your XAML file as AvaloniaResource)


text:
Added Nezly Token (NEZ)

Nezly Token Logo and Assets

We are using BiFrost to convert BTC and ETH to NEZ. As well as XLM/NEZ in StellarTerm directly.
Any missing or suggested configuration help would be greatly appreciated. Thank you!

Resolved pairing errors but now I get:
directory/logos.json
ERROR: logos.json changes needs to be checked in

Run ./checkBuild.sh

Logo transparency
add 10px of space around the logo on each side
Run ./checkBuild.sh

Ok thanx, made transparent image changes with 10px space.. will try to get build on linux to run checkBuild.sh unless you have time to do.

authors: irisli ssalve

repo: irisli/stellarterm


text:
About test images which used by your paper?

Hi, @iro-cp , I can't find the test images in nyu official website.
Can you provide origin test_images used by your paper?
As I think that only use the same test_images can validation inference. And it's important to unify the same standard.

as we say in the paper, it is the validationset of NYU-depth v2 (https://cs.nyu.edu/~silberman/datasets/nyu_depth_v2.html)

repo: iro-cp/FCRN-DepthPrediction


text:
Documentation, HTTP status codes, and Test tweaks

All tests pass.

Wording has been updated. We can tweak as much as needed leading up to 1.0.0.
Adding pounds.


text:
Template Helper: Region-Check

It would be nice to have a build-in region-check template helper like this:
{{#if region 'footer'}}
<div class="outer-wrapper">
    {{> yield region='footer'}}
</div>
{{/if}}

Currently you have to do this by your self and its possible - just saying that this is a nice feature which would be good to have built in.

+1
It would be very usefull.

TimoRuetten, can you tell me how did you solved this?

I've found this in iron_layout.js:
/**                                                                                // 377
   * Check to see if a given region is currently rendered to.                                                          // 378
   *                                                                                // 379
   * Example:                                                                                // 380
   *    {{#if hasRegion 'aside'}}                                                                                // 381
   *      <aside>                                                                                // 382
   *        {{> yield "aside"}}                                                                                // 383
   *      </aside>                                                                                // 384
   *    {{/if}}                                                                                // 385
   */                                                                                // 386
  UI.registerHelper('hasRegion', function (region) {                                                                   // 387
    var layout = findFirstLayout(Blaze.getView());                                                                     // 388
                                                                                // 389
    if (!layout)                                                                                // 390
      throw new Error("No Iron.Layout found so you can't use hasRegion!");                                             // 391
                                                                                // 392
    if (!_.isString(region))                                                                                // 393
      throw new Error("You need to provide an region argument to hasRegion");                                          // 394
                                                                                // 395
    return !! layout.region(region).template();                                                                        // 396
  });

It works, but it's probably not documented yet.
https://github.com/iron-meteor/iron-layout/commit/7622bf5f79775fcd4ab21c9d136cd6b2d7148256

@donwojtallo Nice job - you have found the template helper. And yes, you're right: its not documented yet. Would be nice to add this to the docs.

authors: TimoRuetten donwojtallo

repo: iron-meteor/iron-router

license: mit


text:
Adding a from_str method

This is to allow the use of the FromStr trait to create a Url directly from string, and for example use:
let u = "https://en.wikipedia.org/wiki/Rust_(programming_language)".parse().unwrap();
let redirect = iron::modifiers::Redirect(u);

instead of:
let u = iron::Url::parse("https://en.wikipedia.org/wiki/Rust_(programming_language)").unwrap();
let redirect = iron::modifiers::Redirect(u);

Looks good, I agree this is an improvement! Do you think we should add a test as well? :)

@Hoverbear When I looked at adding tests, I realised they'd all be exactly the same as for Url parse().
I guess we could add one simple positive + one simple negative test to ensure the code is not broken, then rely on parse() for the rest? Let me know what you think.

Yeah that's kind of what I thought too. :S I guess it's fine as is.

Thanks for this contribution! :) We really appreciate it!

authors: Hoverbear dorfsmay

repo: iron/iron


text:
Cannot write more than once

I have specified the option of append mode, but fruits.parquet has only the first 2 row (apples & Oranges). What am I missing?
Thanks!
var opts = {flags: 'a'};
var writer = await parquet.ParquetWriter.openFile(schema, 'fruits.parquet', opts);
// append a few rows to the file
await writer.appendRow({name: 'apples', quantity: 10, price: 2.5, date: new Date(), in_stock: true});
await writer.appendRow({name: 'oranges', quantity: 10, price: 2.5, date: new Date(), in_stock: true});
write.close();
writer = await parquet.ParquetWriter.openFile(schema, 'fruits.parquet', opts);
// append a few rows to the file
await writer.appendRow({name: 'banana', quantity: 10, price: 2.5, date: new Date(), in_stock: true});
await writer.appendRow({name: 'peaches', quantity: 10, price: 2.5, date: new Date(), in_stock: true});
write.close();

Appending to a parquet file is a little more complicated than specifying append flag on the file, as the file has a metadata and footer at the end of the file.
One way to do a pure append, is first read the metadata and then append manually to the file, and finalize by writing the updated metadata and the footer at the end.  The old metadata would be essentially orphaned off.

FWIW: I just grouped all the rows I needed for a particular parquet file into a custom data structure. Once built, I looped through that structure and appended to the parquet file within a single open/close block. Solved the problem of having to worry about appending via the parquetJS api.

authors: ZJONSSON alienintheheights balajiaruna

repo: ironSource/parquetjs


text:
Upgrade K8s Dependencies to v0.30.4

This PR upgrades our Kubernetes package dependencies from v0.29.4 to v0.30.4 and implements necessary code refactoring to accommodate breaking changes.
Proposed Changes:

Upgrade K8s Dependencies: Bumped k8s.io/* dependencies from v0.29.4 to v0.30.4 to incorporate the latest features and improvements. Fixes #1113
Upgrade Controller-Runtime: Bumped sigs.k8s.io/controller-runtime from v0.17.3 to v0.18.5 to ensure compatibility with the upgraded k8s dependencies.
Refactor for Breaking Changes: Adjusted code to address breaking changes introduced in the new version.
Update Code Generation Script: Adapted hack/update-codegen.sh script to utilize the kube_codegen.sh script functions, aligning with updated k8s code generation standards.
Update OpenAPI-Gen Package: The openapi-gen has been removed from k8s.io/code-generator by PR #123529 because it is redundant with the version in k8s.io/kube-openapi.
Update Makefile: Updated ENVTEST_K8S_VERSION from 1.28.0 to 1.30.3 and performed cleanup by removing obsolete generation tool binaries.
Run Make Generate: Executed make generate to apply all code generation tasks with the updated setup.
Update Import Paths: Updated import paths to match the new locations of the generated client code.
Update GitHub Actions: Added step to download k8s.io/code-generator before executing tests and code generation to ensure the module is properly fetched for update-codegen.sh.

Fixes #1094

For me make generate fails on an clean project with:
./hack/update-codegen.sh: line 12: /kube_codegen.sh: No such file or directory

I would suggest to modify the hack script to fetch it from the correct location in the go mod cache.

For me make generate fails on an clean project with:
./hack/update-codegen.sh: line 12: /kube_codegen.sh: No such file or directory

I would suggest to modify the hack script to fetch it from the correct location in the go mod cache.

Thanks for catching this issue. I have addressed this in the latest commit by reordering the steps in the hack script to download dependencies before setting CODE_GEN_DIR. This should resolve the problem, and make generate should now work as expected on a clean project.

repo: ironcore-dev/ironcore


text:
status bar count fix

Make done/cancelled token names consistent, fixing #82

Thanks for doing this! Could you double check that the syntax highlighting still works when you have markdown within the task item? That was one of the reasons I kept changing these around :)

As far as I can tell, the highlighting is unchanged when I revert to the release.

I pulled this in locally and it does check out, but i think we actually should re-visit the code. Changing the classnames like this is a bit of a bandaid (primarily because i didn't really understand how to pull in the markdown syntax!) I have a fix locally that properly enables markdown which i'll put up as a separate pull request for you to take a look :)

Closing this in favor of #85

authors: irrationalistic paulroub

repo: irrationalistic/atom-tasks


text:
🛑 Web Kabupaten/Kota is down

In e455c4a, Web Kabupaten/Kota (https://jemberkab.bps.go.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Web Kabupaten/Kota is back up in a633d2f after 17 minutes.

repo: irsadarief/uptime


text:
how to calculate the confidence map of optical flow,?

how to calculate the confidence map of optical flow,?

We don't need confidence map for optical flow. You can just directly warp the flow to occluded pixels.

repo: irsisyphus/reconet


text:
[8.0.0-beta.4] Next.js Image component blink when changing the language

Describe the bug
Next.js Image component blink when changing the language, with html img tag works fine
Occurs in next-i18next version
8.0.0-beta.4
Steps to reproduce
You have to click to change the language and look at the image. Sometimes it works fine, but most of the time the image blinks
import Link from 'next/link'
import {useRouter} from 'next/router'
import Image from 'next/image'

import {useTranslation} from 'next-i18next'
import {serverSideTranslations} from 'next-i18next/serverSideTranslations'

import {Header} from '../components/Header'
import {Footer} from '../components/Footer'

const Homepage = () => {

    const router = useRouter()
    const {t} = useTranslation('common')

    return (
        <>

                    <Link
                        href='/'
                        locale={router.locale === 'en' ? 'de' : 'en'}
                    >
                        <button>
                            {t('change-locale')}
                        </button>
                    </Link>
                    <Link href='/second-page'>
                        <button
                            type='button'
                        >
                            {t('to-second-page')}
                        </button>
                    </Link>
                    <Image
                        src="https://images.newscientist.com/wp-content/uploads/2019/04/08111018/screenshot-2019-04-08-10.24.34.jpg?width=300"
                        width={100} height={100}/>

        </>
    )
}

export const getStaticProps = async ({locale}) => {
    return {
        props: {
            ...
                await serverSideTranslations(locale, ['common', 'footer']),
        }
    }
}

export default Homepage

Expected behaviour
Image from next/image should not blink

Do you have a reproducible repo? I highly doubt this is related to next-i18next.

@isaachinman Unfortunately no, it is a closed project. However, I tried to reproduce it on your example and the behavior of the pictures is the same.
You need to insert a couple of lines into your example
file examples/simple/pages/index.js
import Link from 'next/link'
import {useRouter} from 'next/router'
import Image from 'next/image'

import {useTranslation} from 'next-i18next'
import {serverSideTranslations} from 'next-i18next/serverSideTranslations'

import {Header} from '../components/Header'
import {Footer} from '../components/Footer'

const Homepage = () => {

    const router = useRouter()
    const {t} = useTranslation('common')

    return (
        <>

                    <Link
                        href='/'
                        locale={router.locale === 'en' ? 'de' : 'en'}
                    >
                        <button>
                            {t('change-locale')}
                        </button>
                    </Link>
                    <Link href='/second-page'>
                        <button
                            type='button'
                        >
                            {t('to-second-page')}
                        </button>
                    </Link>
                    <Image
                        src="https://images.newscientist.com/wp-content/uploads/2019/04/08111018/screenshot-2019-04-08-10.24.34.jpg?width=300"
                        width={100} height={100}/>

        </>
    )
}

export const getStaticProps = async ({locale}) => {
    return {
        props: {
            ...
                await serverSideTranslations(locale, ['common', 'footer']),
        }
    }
}

export default Homepage

file examples/simple/next.config.js
module.exports = {
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'de'],
  },
  images: {
    domains: ["images.newscientist.com"],
  }
}

@ivnmood I think you should open an issue on the main NextJs repo – all that's happening here is that a React component tree is re-rendering. If there are visual inconsistencies within next/image, there's not much next-i18next can do about it. Let me know what you think.

I've learned a quick tip that if you set a key on the Next Image component is prevents re-renders sometimes.

@mirshko That makes sense, and is just general to React. You might also experiment with useMemo or pure components.

authors: isaachinman ivnmood mirshko


text:
IsarError: Could not initialize IsarCore library

On Some devices (Google Pixel 3a(Snapdragon 670)), it is working perfectly fine. But on some devices (Example: Samsung Galaxy A10(Exynos 7884)) it shows this error:
Unhandled Exception: IsarError: Could not initialize IsarCore library. If you create a Flutter app, make sure to add isar_flutter_libs to your dependencies: Invalid argument(s): Failed to load dynamic library 'libisar.so': dlopen failed: cannot locate symbol "__emutls_get_address" referenced by "/data/app/.......==/lib/arm/libisar.so"...
Version

Platform: Android
Flutter version: 3.0.1
Isar version: 2.5.0
Isar Generator version: 2.5.0

I think it's the same issue with 32 bit devices(#281), a galaxy A10 should 64 bit, but it seems that it runs on 32 bit mode (refer to this discussion : https://android.stackexchange.com/questions/225314/is-the-cpu-of-samsung-galaxy-a10s-64-bit-or-32-bit), you can try upgrading to isar 3.0.0 and see if it fixes the issue

I think it's the same issue with 32 bit devices(#281), a galaxy A10 should 64 bit, but it seems that it runs on 32 bit mode (refer to this discussion : https://android.stackexchange.com/questions/225314/is-the-cpu-of-samsung-galaxy-a10s-64-bit-or-32-bit), you can try upgrading to isar 3.0.0 and see if it fixes the issue

Isar 3.0.0 is not stable yet.

I think you have no other choice. I am using Isar 3.0.0 dev in production right now, if you look at the generated files you will notice that there aren't many changes, and there are no breaking changes to the core API's.

I think it's the same issue with 32 bit devices(#281), a galaxy A10 should 64 bit, but it seems that it runs on 32 bit mode (refer to this discussion : https://android.stackexchange.com/questions/225314/is-the-cpu-of-samsung-galaxy-a10s-64-bit-or-32-bit), you can try upgrading to isar 3.0.0 and see if it fixes the issue

I have same issue with Isar 2.5.0 in 32bit devices(Motorola XT1626, Android 7.0), after upgrade to Isar 3.0.0 i solved my issue.

Awesome, thanks for confirming @rodevapp

authors: Anan-Saadi jeremylcarter leisim rodevapp santoshakil

repo: isar/isar


text:
NameError: name 'Logger' is not defined

I just ran into an error due to an undefined Logger variable here:
test_isofit_enmap.py:122:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../enpt/processors/atmospheric_correction/_isofit_enmap.py:571: in _run
    ).run(row_column=None)
../../../../miniforge3/envs/enpt_dev_isofit321/lib/python3.12/site-packages/isofit/core/isofit.py:114: in run
    self.fm = fm = ForwardModel(self.config)
../../../../miniforge3/envs/enpt_dev_isofit321/lib/python3.12/site-packages/isofit/core/forward.py:74: in __init__
    self.RT = RadiativeTransfer(self.full_config)
../../../../miniforge3/envs/enpt_dev_isofit321/lib/python3.12/site-packages/isofit/radiative_transfer/radiative_transfer.py:101: NameError

NameError: name 'Logger' is not defined

Should be an easy fix..

Thanks for catching this! It looks like the Logger definition is missing from radiative_transfer.py. I agree that this should be an easy fix. I'll put a PR together.
The missing Logger is catching because the config is failing a built-in error check between the length of the config statevectors and the and the length of the rte statevector elements.
            # Make sure the length of the config statevectores match the engine's assumed statevectors
            if (expected := len(config.statevector.get_element_names())) != (
                got := len(rte.indices.x_RT)
            ):
                error = f"Mismatch between the number of elements for the config statevector and LUT.indices.x_RT: {expected=}, {got=}"
                Logger.error(error)
                raise AttributeError(error)

You may have already resolved this, but in the meantime, I can also help resolve the config mismatch, which would circumvent the Logger issue.

It's hard to know exactly what your config set-up error is without looking at your config directly, but my guess is that it is along these lines:
I was able to reproduce the error by passing isofit run a config where in the config JSON the length of the statevector_names entry does not match the number of keys in the statevector entry.
The root of the NameError was spot on and adding the missing definition fixed that issue. Just wanted to give some context around how to fix the AttributeError that will pop up once the Logger is fixed before this issue is closed.

Thanks @evan-greenbrg, the reason for running into this error was in my particular case that I provided a LUT which had a variable and dimension called "surface_elevation". However, ISOFIT  expects it be named "surface_elevation_km". Therefore, surface_elevation was not recognized as a geometry variable which caused the mismatch.
To me, the error message itself makes sense from the developer point of view but requires to know what LUT.indices.x_RT actually is (the usual user does not know this). Yesterday, @unbohn sent me the naming convention of the variables and dimensions that should be contained in the LUT (at least for the geometry variables) and I am wondering why ISOFIT not simply performs a check if the actual LUT variables conform to this naming convention:
geometry_input_names = [
        "observer_azimuth",
        "observer_zenith",
        "solar_azimuth",
        "solar_zenith",
        "relative_azimuth",
        "observer_altitude_km",
        "surface_elevation_km",
    ]

This should avoid subsequent issues as the one above and should provide the user a less cryptic error message.

First comment (logging import) now handled, leaving open for addressing the other comments.

authors: danschef evan-greenbrg pgbrodrick

repo: isofit/isofit


text:
Fix asan stacktrace entry parsing

ASAN: Rust panic in parse_stacktrace_entry (line) while parsing invalid entry:
      #4 0x998b40 in (anonymous namespace)::decrypt_xl<unsigned char> > const&) /xlnt/er+0x426cbd)

Add this example to tests, please

ASAN: Rust panic in parse_stacktrace_entry (line) while parsing invalid entry:
      #4 0x998b40 in (anonymous namespace)::decrypt_xl<unsigned char> > const&) /xlnt/er+0x426cbd)

The thing is that this entry is valid. We just cannot handle it ATM. We should change parsing code. Thus, we can correctly parse it.

repo: ispras/casr


text:
Scheduled FIRRTL output format

Separate issue for scheduled FIRRTL output format, mentioned in #22.

Closed with #40.

repo: ispras/utopia-hls


text:
istioctl manifest: Install CNI daemonset/pods in another namespace

Previously (or currently) CNI components can be - and are - encouraged to be installed on kube-system namespace:
$ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=kube-system | kubectl apply -f -

This way users can setup additional priorities for pod scheduling like system-node-critical.
With the istioctl manifest method, those components are installed in istio-system namespace.
Is there an way to install them in a different namespace like it's possible with helm?

cc @sdake @ostromart @rlenglet

This is incorrect. It had to be created in kube-system due to using the system-node-critical priority class. This is no longer required in 1.4, where we use the system-cluster-critical priority class.

cc @ruigulala

That said, for some reason, istio/installer has forked the Helm chart seemingly months ago and never sinced again: https://github.com/istio/installer/blob/release-1.4/istio-cni/templates/daemonset.yaml It does even have the priorityClass. This is a recipe for disaster. @jwendell I'd recommend rewording the issue about istio/installer being way out of sync with upstream istio/cni.

istio/installer CNI charts being out of sync with istio/cni is a release blocker IMHO. @istio/release-managers-1-4

@rlenglet Do you know who is the source of truth when we talk about charts? It's confusing to me.
So, we have charts in istio/cni, then install/cni. We also have istio/operator. Where does istioctl manifest copy them from? Which one does it use?

istioctl imports the operator as go code. The operator has the charts built
into the go code using the vfsgen stuff. Those charts are from
istio/installer.
istio/cni also has charts that are shipped as part of the helm install
On Sat, Nov 2, 2019, 8:42 AM Jonh Wendell notifications@github.com wrote:

@rlenglet https://github.com/rlenglet Do you know who is the source of
truth when we talk about charts? It's confusing to me.
So, we have charts in istio/cni, then install/cni. We also have
istio/operator. Where does istioctl manifest copy them from? Which one
does it use?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/18576?email_source=notifications&email_token=AAEYGXJVS7GX5IPBIQ2FDFDQRWNXBA5CNFSM4JIGE5CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC46V2Q#issuecomment-549055210,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXIRY4A7MQ4HVJWZRDDQRWNXBANCNFSM4JIGE5CA
.

I've created https://github.com/istio/installer/pull/476
Could someone from CNI team please verify if it's enough?

@rlenglet Do you know who is the source of truth when we talk about charts? It's confusing to me.
So, we have charts in istio/cni, then install/cni. We also have istio/operator. Where does istioctl manifest copy them from? Which one does it use?

The source of truth, for the time being, is istio/installer repo. We plan to delete charts from other repositories including this one to centralize the installation charts.  In istio/istio, the install directory has taken a hard line on merging changes to installer first. Sadly that was not done with this repo.
Cheers
-steve

authors: howardjohn jwendell rlenglet sdake

repo: istio/istio


text:
some problem this SNI when using --tlsv1.3

Bug description
We have gke cluster with custom istio installation 1.2.6.
With gateway configuration like this
spec:
  servers:
  - hosts:
    - cfg.mysiteaddress.ru
    port:
      name: https-mysite
      number: 443
      protocol: HTTPS
    tls:
      credentialName: cert.mysiteaddress
      maxProtocolVersion: TLSV1_3
      minProtocolVersion: TLSV1_1
      mode: SIMPLE
  - hosts:
    - "*"
    port:
      name: https-all
      number: 443
      protocol: HTTPS
    tls:
      credentialName: wildcard.cert
      mode: SIMPLE

and we have external services that has connections to our service cfg.mysiteaddress.ru. There are were working fine.
But then we update istio to 1.3.4 the external services begin to fail connections: Error: self signed certificate
With debuging we saw wrong certificate wildcard.cert from "*" host but gw config haven't been changed.
Also one strange thing - a browsers connecting to cfg.mysiteaddress.ru well.
So we found this problem:
curl https://cfg.mysiteaddress.ru -Iv --tlsv1.2  - works fine
curl https://cfg.mysiteaddress.ru -Iv --tlsv1.3 - faild SSL: no alternative certificate subject name matches target host name, because get default cert
I made tcpdump and compare packets - both has correct sni cfg.mysiteaddress.ru
Expected behavior
Expected successed response
Steps to reproduce the bug
set gw config from this message
curl https://cfg.mysiteaddress.ru -Iv --tlsv1.3
but get cert from default host
Version (include the output of istioctl version --remote and kubectl version)
1.2.6
1.3.4
How was Istio installed?
manually with our custom specs
Environment where bug was observed (cloud vendor, OS, etc)
gke

@turbotankist , could you please provide Envoy log and config dump if possible? I am not clear why curl https://cfg.mysiteaddress.ru -Iv --tlsv1.2 works fine while curl https://cfg.mysiteaddress.ru -Iv --tlsv1.3 fails. If the listener that is serving cfg.mysiteaddress.ru uses wrong cert wildcard.cert, both curl requests should fail.
@PiotrSikora Are you aware of any SNI changes that might cause this failure?

I have do this
curl https://cfg.mysiteaddress.ru/ -Ikv --tlsv1.3 -A tls13
curl https://cfg.mysiteaddress.ru/ -Iv --tlsv1.2 -A tls12

and get this logs:
[2019-12-06T13:26:06.847Z] "HEAD / HTTP/2" 301 - "-" 0 0 0 - "172.27.72.224" "tls13" "7fab0768-470a-4cf8-9f01-8ae83744bb56" "cfg.mysiteaddress.ru" "-" - - 10.110.73.82:443 172.27.72.224:51072 -
[2019-12-06T13:26:15.446Z] "HEAD / HTTP/2" 301 - "-" 0 0 0 - "172.27.72.224" "tls12" "5d864d19-1049-4105-92bd-96ebef9a6c32" "cfg.mysiteaddress.ru "-" - - 10.110.73.82:443 172.27.72.224:51078 cfg.mysiteaddress.ru

the last value in the log is %REQUESTED_SERVER_NAME%
why envoy didn't see it if curl with  --tlsv1.3

This does not sound like a SDS issue. The handshake is completed and Envoy returns 301. I will let @PiotrSikora to take a look.

I can confirm this is still an issue with Istio 1.4.2. Unexpectedly we dropped TLSv1.3 support according to TLS test sites (such as Qualys SSLLabs) with the move to Istio (coming from plain Envoy).
What surprised me even more is that curl in auto-mode does get it to negotiate TLSv1.3, but with minimal version 1.3 it doesn't. This is probably because the TLS Client Hello looks different.

@turbotankist could you send me your name over email (my github username at google.com), so that we could include it in the credits for the security release? Thank you. cc @lizan

authors: JimmyCYJ PiotrSikora gertvdijk turbotankist


text:
Envoy's access logging is not working

Bug description
Following this demo: https://istio.io/docs/tasks/telemetry/logs/access-log/#enable-envoy-s-access-logging
Admins-MBP:~ admin$ kubectl logs -l app=sleep -c istio-proxy
2019-11-13T15:03:14.816677Z	info	Received new config, resetting budget
2019-11-13T15:03:14.816686Z	info	Reconciling retry (budget 10)
2019-11-13T15:03:14.816691Z	info	watching /etc/certs for changes
2019-11-13T15:03:14.816706Z	info	Epoch 0 starting
2019-11-13T15:03:14.821083Z	info	Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster sleep.default --service-node sidecar~10.0.11.89~sleep-6f459785b8-gblt2.default~default.svc.cluster.local --max-obj-name-len 189 --local-address-ip-version v4 --allow-unknown-fields -l warning --component-log-level misc:error --concurrency 2]
[2019-11-13 15:03:14.836][15][warning][config] [external/envoy/source/server/options_impl.cc:193] --allow-unknown-fields is deprecated, use --allow-unknown-static-fields instead.
[2019-11-13 15:03:14.855][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:87] gRPC config stream closed: 14, no healthy upstream
[2019-11-13 15:03:14.855][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:50] Unable to establish new stream
2019-11-13T15:03:16.464381Z	info	Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2019-11-13T15:03:18.464612Z	info	Envoy proxy is ready

Admins-MBP:~ admin$ kubectl logs -l app=httpbin -c istio-proxy
2019-11-13T15:04:08.421365Z	info	watching /etc/certs for changes
2019-11-13T15:04:08.421389Z	info	Received new config, resetting budget
2019-11-13T15:04:08.421392Z	info	Reconciling retry (budget 10)
2019-11-13T15:04:08.421399Z	info	Epoch 0 starting
2019-11-13T15:04:08.426100Z	info	Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster httpbin.default --service-node sidecar~10.0.11.77~httpbin-775f6cf7d8-grcv4.default~default.svc.cluster.local --max-obj-name-len 189 --local-address-ip-version v4 --allow-unknown-fields -l warning --component-log-level misc:error --concurrency 2]
[2019-11-13 15:04:08.438][13][warning][config] [external/envoy/source/server/options_impl.cc:193] --allow-unknown-fields is deprecated, use --allow-unknown-static-fields instead.
[2019-11-13 15:04:08.464][13][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:87] gRPC config stream closed: 14, no healthy upstream
[2019-11-13 15:04:08.464][13][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:50] Unable to establish new stream
2019-11-13T15:04:09.884633Z	info	Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2019-11-13T15:04:11.884755Z	info	Envoy proxy is ready

I cannot see any log entries. How can I verify if everything is set up correctly? Is there any way to see current installation options?
Expected behavior
It should log access log data.
Steps to reproduce the bug
Install istio using helm template and follow the steps from the demo tutorial.
Version (include the output of istioctl version --remote and kubectl version)
1.3.5
How was Istio installed?
Helm template
Environment where bug was observed (cloud vendor, OS, etc)
AKS
Additional Data - istioctl proxy-status
sleep-6f459785b8-gblt2.default                         SYNCED     SYNCED     SYNCED     SYNCED     istio-pilot-5dfb9cfc7c-fw79m     1.3.5
httpbin-775f6cf7d8-grcv4.default                       SYNCED     SYNCED     SYNCED     SYNCED     istio-pilot-5dfb9cfc7c-fw79m     1.3.5

you can see the current config from the istio config map in istio-system, look for access log file. You can also get a config dump from a proxy and should see access log settings there if it's applied correctly

@howardjohn It's empty. :(
# Set accessLogFile to empty string to disable access log.
accessLogFile: ""

I am setting this from main values.yaml file. Not sure why it's not set up.
global:
  proxy:
  # Configuration for the proxy init container
  init:
    resources:
      limits:
        cpu: 100m
        memory: 50Mi
      requests:
        cpu: 10m
        memory: 10Mi
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 256Mi
  image: proxyv2
  accessLogFile: "/dev/stdout"
  accessLogEncoding: "TEXT"

Your indent is off
You want
global:
  proxy:
    image: proxyv2
    accessLogFile: "/dev/stdout"
    accessLogEncoding: "TEXT"

That's how it is in the actual file. Indent is missing here only.

Are you sure its not just a space vs tab issue or something?
https://github.com/istio/istio/blob/2b971c71aa807f777219c1bf64ed6932770d6f06/install/kubernetes/helm/istio/templates/configmap.yaml#L41

@howardjohn Such a silly mistake. Actually, I added manually accessLogFile: "/dev/stdout" before the default value which is blank. It was overwriting the given value. Thanks for your help.

authors: howardjohn rnkhouse


text:
Discovery Process reporting Pod Not Found - causing endpoints to be out of date

Bug description
Occasionally during a large deployment Istio Pilot will start reporting the following message hundreds of times until restarted.

2020-04-21T11:14:21.227902Z	warn	failed to get pod platform/abc-5674bc9fb7-mxpzt from kube-apiserver: pods "abc-5674bc9fb7-mxpzt" not found

This causes all the endpoints on some sidecars to be out of date and client sidecars start sending traffic to the wrong endpoint IP addresses. The only way to resolve is to restart the Pilots and then the error message goes away and discovery happens as normal.
istioctl proxy-status shows all sidecars as being in sync.
During this time i also see a long spike of endpoints without ip until i restart pilot

(time shown in GMT+2)
Expected behavior
Discovery process happens as normal and endpoints are not out of date
Steps to reproduce the bug
Run a large deployment of dozens of pods
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
client version: 1.4.4
control plane version: 1.4.7
data plane version: 1.4.7 (1254 proxies), 1.4.3 (230 proxies), 1.4.0 (85 proxies)
How was Istio installed?
helm
Environment where bug was observed (cloud vendor, OS, etc)
Amazon EKS

when it logs pods "abc-5674bc9fb7-mxpzt" not found is it correct that the pod does not exist? Or is it trying to query a pod that does not exist?
Seems related to https://github.com/istio/istio/issues/20676 maybe but that is fixed in 1.4.7

This logs when:

An endpoint is changed
The IP in that endpoint does not have an associated pod in pilot's internal cache
We directly query k8s for the pod, and it does not exist

So seems like two possibilities:

Your kubernetes cluster somehow has stale endpoints, so the pod is removed but the ip address is still referenced in the Endpoint
Pilot is somehow reading stale endpoints, but they are correct in Kubernetes. Based on pilot restart fixing things it may be this - although I am not quite sure how this would happen.

Not sure if its possible for you to look back at the endpoints to see if they were correct?
Looking into this a bit more, thats my initial thoughts though

client sidecars start sending traffic to the wrong endpoint IP addresses

What is "wrong" in this case? I would guess that these endpoints without pods are just excluded from the list of endpoints

client sidecars start sending traffic to the wrong endpoint IP addresses

What is "wrong" in this case? I would guess that these endpoints without pods are just excluded from the list of endpoints

For example: when I look on our istio-gateways and run
istioctl proxy-config endpoints servicename I see some of the ip addresses it lists out are incorrect / out of date. So when traffic comes into the gateway it returns a 5xx since it cannot reach that up. However, we have multiple gateways and only some of them had wrong endpoints while others were correct.

I am curious how you got the "endpoints with no pods" metric?

We encountered this a couple days ago on GKE with Istio 1.4.9. Restarting Pilot fixed the issue at the time and we haven't seen it since.

What is "wrong" in this case? I would guess that these endpoints without pods are just excluded from the list of endpoints

We saw traffic for one service end up at a completely different unrelated service, bypassing its VirtualService configuration. Scary from a security perspective. I assume the pod IPs were recycled while Pilot was stuck in a loop for about an hour.

Saw this again a couple times in the last few weeks. Restarting Pilot always immediately fixes the issue.
At least in one case, memory usage increased continuously for a pilot stuck in the "failed to get pod" state:

The first "failed to get pod" message showed up at 9:58 AM and continued until 3:45 PM when the Pilot pod was restarted.
I decided to look at the logs for one of the application pods, and ended up with more questions than answers:
Application pod: skm2b
Pilot pods: s65wm (health), lnjvs (healthy), xmkzr (problem child)

2020-06-09 11:24:33.173 - Application pod skm2b is deleted by replicaset controller
2020-06-09 11:24:33.178 - Endpoint update that still contains skm2b
2020-06-09 11:24:33.189 - Endpoint update that still contains skm2b failed due to a conflict
2020-06-09 11:24:33.199 - Endpoint update without skm2b
2020-06-09 11:24:40.032 - Pod skm2b is deleted by the node
2020-06-09 11:24:40.034 - istio-pilot-s65wm info Handling event delete for pod foo-skm2b in namespace foo -> 10.24.86.30
2020-06-09 11:24:40.035 - istio-pilot-lnjvs info Handling event delete for pod foo-skm2b in namespace foo -> 10.24.86.30
2020-06-09 12:46:37.169 - istio-pilot-xmkzr info Handling event update for pod foo-skm2b in namespace foo -> 10.24.86.30
2020-06-09 12:48:08.970 - istio-pilot-xmkzr info Handling event update for pod foo-skm2b in namespace foo -> 10.24.86.30
2020-06-09 12:48:08.970 - istio-pilot-xmkzr info Handling event update for pod foo-skm2b in namespace foo -> 10.24.86.30
2020-06-09 12:48:32.568 - istio-pilot-xmkzr info Handling event update for pod foo-skm2b in namespace foo -> 10.24.86.30
2020-06-09 12:48:38.569 - istio-pilot-xmkzr warn failed to get pod foo/foo-skm2b from kube-apiserver: pods "foo-skm2b" not found
2020-06-09 12:48:38.569 - istio-pilot-xmkzr error Endpoint without pod 10.24.86.30 foo.foo
... couple hundred identical messages about skm2b ...
2020-06-09 14:37:06.369 - istio-pilot-xmkzr warn failed to get pod foo/foo-skm2b from kube-apiserver: pods "foo-skm2b" not found
2020-06-09 14:37:06.369 - istio-pilot-xmkzr error Endpoint without pod 10.24.86.30 foo.foo

Notice the ~80min gap for pilot xmkzr to process events for skm2b, and they're not even the deletions! I glanced through xmkzr logs but did not find any clues as to why it would be delayed so much.
We'll try the 1.4.4 pilot and see if the problem goes away.

@kornholi We updated to Istio 1.5.4 and still occasionally see this issue

I am nearly certain this is fixed by https://github.com/istio/istio/issues/25112. Lets move the conversation there, in particular if the fixed provided there does not solve this. Thanks!

authors: crhuber howardjohn kornholi suchita-jain


text:
Released Helm charts are not up to date

Bug description
The correct Helm charts to install Istio 1.5.2 are located in manifests/charts.
But the 1.5.2 release  is releasing old charts.
Expected behaviour
The officially released charts should be up to date.
Steps to reproduce the bug
helm repo add istio.io https://storage.googleapis.com/istio-release/releases/1.5.2/charts/
kubectl create namespace istio-system
helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -
kubectl -n istio-system wait --for=condition=complete job --all
helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f -

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T23:41:55Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.11-eks-af3caf", GitCommit:"af3caf6136cd355f467083651cc1010a499f59b1", GitTreeState:"clean", BuildDate:"2020-03-27T21:51:36Z", GoVersion:"go1.12.17", Compiler:"gc", Platform:"linux/amd64"}
$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

How was Istio installed?
Helm via Terraform
Environment where bug was observed (cloud vendor, OS, etc)
Unrelated

In 1.5 there are two sets of helm charts - one under manifests/ and other under install/. The install/ ones are legacy and removed in 1.6; this is what is published. The manifests/ ones are meant to be installed via https://istio.io/docs/setup/install/istioctl/

Excellent! IMHO this should be noted in the docs and if possible/easy can you please consider publishing the manifests/ charts?
Is the idea that all installation methods will be deprecated soon in favour of istioctl, if so when? If helm is not to be supported anymore is there a link to the discussion where that decision was made?
I'm new to Istio and really trying to understand what I stand to gain by reworking my automation to use istioctl vs helm.

I found answers to my questions @howardjohn sorry for asking before googling :(
Timeline for helm deprecation
To istioctl or to helm

authors: Stratouklos howardjohn


text:
[istio-proxy] envoyMetricsService should work with auto mTLS

Describe the feature request
https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig
The defaultConfig.envoyMetricsService DNS resolves the address to an IP. It then uses that IP to make outbound requests. To use TLS, it has tlsSettings which is a DestinationRule under the covers.
This is not compatible with mTLS between pods in a mesh. The envoy doesn't know that the IP is a part of the mesh (it doesn't use the outbound rule). The requests return a termination error:
spec:
  meshConfig:
    defaultConfig:
      envoyMetricsService:
        address: my-metrics-service:9818

':method', 'POST'
':path', '/envoy.service.metrics.v2.MetricsService/StreamMetrics'
':authority', 'envoy_metrics_service'
':scheme', 'http'
'te', 'trailers'
'content-type', 'application/grpc'
'x-envoy-internal', 'true'
'x-forwarded-for', '172.30.112.125'

'grpc-status', '14'
'grpc-message', 'upstream connect error or disconnect/reset before headers. reset reason: connection termination'

grpc curling a metrics request from a go pod to my metricsService succeeds and it is auto converted to mTLS. This works because I'm using the hostname directly, not the IP of the metricsService k8s service.
grpcurl -d '{"identifier": {"node": {}}, "envoy_metrics": []}' -plaintext my-metrics-service:9818 envoy.service.metrics.v2.MetricsService/StreamMetrics

'grpc-status', '0'
'grpc-message', ''

':method', 'POST'
':scheme', 'http'
':path', '/envoy.service.metrics.v2.MetricsService/StreamMetrics'
':authority', 'my-metrics-service:9818'
'content-type', 'application/grpc'
'user-agent', 'grpc-go/1.33.0-dev'
'te', 'trailers'

':method', 'POST'
':scheme', 'https'
':path', '/envoy.service.metrics.v2.MetricsService/StreamMetrics'
':authority', 'my-metrics-service:9818'
'content-type', 'application/grpc'
'user-agent', 'grpc-go/1.33.0-dev'
'te', 'trailers'
'x-forwarded-proto', 'http'
'x-request-id', 'b3bd7f8f-fa39-426b-ba11-e94cc3e95a06'
'x-envoy-decorator-operation', 'my-metrics-service.default.svc.cluster.local:9818/*'
'x-envoy-peer-metadata', '<REDACTED>'
'x-envoy-peer-metadata-id', 'sidecar~172.30.112.125~sleep-56dd55d645-pgkjj.default~default.svc.cluster.local'
'x-envoy-attempt-count', '1'
'x-b3-traceid', '48c8d97bc52576c71b74be441cf9cc6f'
'x-b3-spanid', '1b74be441cf9cc6f'
'x-b3-sampled', '0'

My actual feature request is to make envoyMetricsService requests use the hostname provided in the address, instead of resolving it and using the IP.
This should also be a problem with tracing and envoyAccessLogService
Describe alternatives you've considered
I have a special use case that needs this kind of implicit mTLS
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[x] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

I think you'll need to set ClientTLSSettings to make it use mTLS?

https://github.com/istio/api/blob/c78f387f78a22a3c4a1c49679dc44cded454530d/mesh/v1alpha1/proxy.proto#L459

@bianpengyuan Hey, ya that does work normally. In my case I'm using SNI passthrough to send metrics from the sidecar to my metrics service in a different cluster. I've added the metrics service to the mesh by adding a sidecar (istioctl proxy-status shows that it's in sync).
I did try using ClientTLSSettings with SNI passthrough, but I run into a connection failure. If the envoyMetricsService resolves the hostname to an IP, then the SNI value would be stripped away. Different problem, same root cause I think.

Thanks @PatrickDuncan - I think you may still be missing some configs so the metrics service isn't registered as part of the mesh properly.  Could you share your SE/Workload entry configs?

authors: PatrickDuncan bianpengyuan linsun


text:
sidecar egress mtls configuration override ROOTCA to cause internal mtls failure

Bug description
I found after adding client cert/key/CA in pod annotation (sidecar.istio.io/userVolume and sidecar.istio.io/userVolumeMount), the CA will override the ROOTCA in envoy proxy configuration, and then internal mtls communication will failed even external mtls is ok.
The client cert/key/CA will be used to connect to external service for MTLS communication ( I use sidecar directly instead of through egress gateway). The annotation will auto add volume/volumeMount to the pod when pod creating, and sidecar can use it later which cert/key/CA path is also identified in DR, and then I add SE and DR to try to enable external mtls communication.
After that, the external mtls is ok, but internal mtls is failed for ROOTCA body is replaced by the new CA in annotation. I don't find the same problem in egress gateway.
More detail can be found in the reproduce steps later.
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[x] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Expected behavior
After configuring sidecar egress mtls (annotation + SE +DR(with cert/key/CA path), internal mtls ROOTCA is not be override and also can work.
Steps to reproduce the bug
0. Create both client cert/key/CA and server client.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt

openssl req -out my-nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-nginx.mesh-external.svc.cluster.local/O=some organization"
openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-nginx.mesh-external.svc.cluster.local.csr -out my-nginx.mesh-external.svc.cluster.local.crt

openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=client organization"
openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 1 -in client.example.com.csr -out client.example.com.crt

kubectl -n hobby create secret generic client-certs-cacert --from-file=ca-chain.cert.pem=./example.com.crt
kubectl -n hobby create secret tls client-certs --cert ./client.example.com.crt --key ./client.example.com.key

1. Deploy client to connect to external mtls server
1.1 deploy sleep with sidecar and client cert/key/CA in NS hobby
kubectl -n hobby apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)

1.2. Add annotation to assign client cert/key/CA
Add the following annotation in sleep deployment to add new volume for cert/key/CA which will be used to communicate with external mtls service later.
         sidecar.istio.io/userVolume: '{"egress-secret":{"secret":{"secretName":"client-certs","optional":true}},"egress-ca-secret":{"secret":{"secretName":"client-certs-cacert"}}}'
        sidecar.istio.io/userVolumeMount: '{"egress-secret":{"mountPath":"/etc/istio/egress-certs/","readOnly":true},"egress-ca-secret":{"mountPath":"/etc/istio/egress-ca-certs/","readOnly":true}}'

2. Add external service mtls configuration (SE + DR) in NS hobby
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: first-service-entry
  namespace: hobby
spec:
  exportTo:
  - .
  hosts:
  - my-nginx.mesh-external.svc.cluster.local
  location: MESH_EXTERNAL
  ports:
  - name: http-port-for-tls-origination
    number: 31443
    protocol: HTTP
  resolution: NONE
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: first-destination-rule
  namespace: hobby
spec:
  exportTo:
  - .
  host: my-nginx.mesh-external.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    portLevelSettings:
    - port:
        number: 31443
      tls:
        caCertificates: /etc/istio/egress-ca-certs/ca-chain.cert.pem
        clientCertificate: /etc/istio/egress-certs/tls.crt
        mode: MUTUAL
        privateKey: /etc/istio/egress-certs/tls.key
        sni: my-nginx.mesh-external.svc.cluster.local
EOF

3. Add external mtls service (ngnix)
kubectl create namespace mesh-external
kubectl create -n mesh-external secret tls nginx-server-certs --key my-nginx.mesh-external.svc.cluster.local.key --cert my-nginx.mesh-external.svc.cluster.local.crt
kubectl create -n mesh-external secret generic nginx-ca-certs --from-file=example.com.crt

$ cat <<\EOF > ./nginx.conf
events {
}

http {
  log_format main '$remote_addr - $remote_user [$time_local]  $status '
  '"$request" $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for"';
  access_log /var/log/nginx/access.log main;
  error_log  /var/log/nginx/error.log;

  server {
    listen 443 ssl;

    root /usr/share/nginx/html;
    index index.html;

    server_name my-nginx.mesh-external.svc.cluster.local;
    ssl_certificate /etc/nginx-server-certs/tls.crt;
    ssl_certificate_key /etc/nginx-server-certs/tls.key;
    ssl_client_certificate /etc/nginx-ca-certs/example.com.crt;
    ssl_verify_client on; # In mutual TLS, server verifies client's certificate
  }
}
EOF

kubectl create configmap nginx-configmap -n mesh-external --from-file=nginx.conf=./nginx.conf

kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  namespace: mesh-external
  labels:
    run: my-nginx
spec:
  ports:
  - port: 31443
    protocol: TCP
    targetPort: 443
  selector:
    run: my-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  namespace: mesh-external
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 1
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 443
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx
          readOnly: true
        - name: nginx-server-certs
          mountPath: /etc/nginx-server-certs
          readOnly: true
        - name: nginx-ca-certs
          mountPath: /etc/nginx-ca-certs
          readOnly: true
      volumes:
      - name: nginx-config
        configMap:
          name: nginx-configmap
      - name: nginx-server-certs
        secret:
          secretName: nginx-server-certs
      - name: nginx-ca-certs
        secret:
          secretName: nginx-ca-certs
EOF

4. Verification Steps
The external mtls communication work correctly as below screenshot, but internal mtls can not work for ROOTCA is replaced by new CA assigned in sleep annotation.
$ kubectl -n hobby exec "$(kubectl -n hobby get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -s http://my-nginx.mesh-external.svc.cluster.local:31443
<!DOCTYPE html>

<title>Welcome to nginx!</title>

Welcome to nginx!

...

The secret of ROOTCA is replaced by ca-chain.cert.pem , you can find the "NOT AFTER" and "NOT BEFORE" are the same now
$ istioctl pc secret sleep-747dcdbd6f-rbpkx.hobby
RESOURCE NAME                                                                 TYPE           STATUS     VALID CERT     SERIAL NUMBER                                        NOT AFTER                NOT BEFORE
file-cert:/etc/istio/egress-certs/tls.crt~/etc/istio/egress-certs/tls.key     Cert Chain     ACTIVE     true           1                                                    2021-10-20T02:49:14Z     2020-10-20T02:49:14Z
default                                                                       Cert Chain     ACTIVE     true           129588817028178672933431284968727571656              2020-10-21T07:57:35Z     2020-10-20T07:57:35Z
file-root:/etc/istio/egress-ca-certs/ca-chain.cert.pem                        CA             ACTIVE     true           279620839875612486678315663074644359785194352408     2021-10-20T02:48:52Z     2020-10-20T02:48:52Z
ROOTCA                                                                        CA             ACTIVE     true           279620839875612486678315663074644359785194352408     2021-10-20T02:48:52Z     2020-10-20T02:48:52Z

Version (include the output of istioctl version --remote and kubectl version --short and helm version if you used Helm)
$ istioctl version --remote
client version: 1.7.3
control plane version: 1.7.3
data plane version: 1.7.3 (4 proxies)
How was Istio installed?
istioctl install --profile=demo
Environment where bug was observed (cloud vendor, OS, etc)
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.

And the cluster configuration is as below.
$ istioctl  pc cluster sleep-747dcdbd6f-rbpkx.hobby --port 31443 -ojson
[
    {
        "name": "outbound|31443||my-nginx.mesh-external.svc.cluster.local",
        "type": "ORIGINAL_DST",
        "connectTimeout": "10s",
        "lbPolicy": "CLUSTER_PROVIDED",
        "circuitBreakers": {
            "thresholds": [
                {
                    "maxConnections": 4294967295,
                    "maxPendingRequests": 4294967295,
                    "maxRequests": 4294967295,
                    "maxRetries": 4294967295
                }
            ]
        },
        "transportSocket": {
            "name": "envoy.transport_sockets.tls",
            "typedConfig": {
                "@type": "type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext",
                "commonTlsContext": {
                    "tlsCertificateSdsSecretConfigs": [
                        {
                            "name": "file-cert:/etc/istio/egress-certs/tls.crt~/etc/istio/egress-certs/tls.key",
                            "sdsConfig": {
                                "apiConfigSource": {
                                    "apiType": "GRPC",
                                    "transportApiVersion": "V3",
                                    "grpcServices": [
                                        {
                                            "envoyGrpc": {
                                                "clusterName": "sds-grpc"
                                            }
                                        }
                                    ]
                                },
                                "resourceApiVersion": "V3"
                            }
                        }
                    ],
                    "combinedValidationContext": {
                        "defaultValidationContext": {},
                        "validationContextSdsSecretConfig": {
                            "name": "file-root:/etc/istio/egress-ca-certs/ca-chain.cert.pem",
                            "sdsConfig": {
                                "apiConfigSource": {
                                    "apiType": "GRPC",
                                    "transportApiVersion": "V3",
                                    "grpcServices": [
                                        {
                                            "envoyGrpc": {
                                                "clusterName": "sds-grpc"
                                            }
                                        }
                                    ]
                                },
                                "resourceApiVersion": "V3"
                            }
                        }
                    }
                },
                "sni": "my-nginx.mesh-external.svc.cluster.local"
            }
        },
...

@howardjohn  @ramaraochavali @JimmyCYJ do you think if my issue is the same with https://github.com/istio/istio/issues/27218? Thanks

It seems so. Can u verify if that fixed your issue?

@ramaraochavali I have tried istio-1.8.0-alpha.0, and this issue gone, so I think #27218 fixed it. Thanks,

@hobbytp Thanks for the update. I will close this issue then.

authors: hobbytp ramaraochavali


text:
Current documentation does not cover the case to get information about mTLS STRICT status applied using policies.

Current documentation does not cover the case to get information about mTLS STRICT status applied using policies.
Previously this information was provided with command istioctl authn tls-check which showed mTLS modes applied, but current istioctl versions 1.7 and 1.8 doesn't not support this command.
Example in previously Istio releases (1.4):
istioctl authn tls-check productpage-v1-596598f447-6l48d reviews.default.svc.cluster.local
HOST:PORT                                  STATUS     SERVER     CLIENT     AUTHN POLICY     DESTINATION RULE
reviews.default.svc.cluster.local:9080     AUTO       STRICT     -          /default         -

https://github.com/istio/istio/issues/23388
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: bookinfo
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default-peer-authentication
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "mtls-global"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---

istioctl x describe pod productpage-v1-6987489c74-v7bd6.bookinfo
Pod: productpage-v1-6987489c74-v7bd6.bookinfo
   Pod Ports: 9080 (productpage), 15090 (istio-proxy)
--------------------
Service: productpage.bookinfo
   Port: http 9080/HTTP targets pod port 9080
DestinationRule: productpage.bookinfo for "productpage"
   Matching subsets: v1
   Traffic Policy TLS Mode: ISTIO_MUTUAL

Exposed on Ingress Gateway http://
VirtualService: bookinfo.bookinfo
   /productpage, /static*, /login, /logout, /api/v1/products*

I tried to use tcpdump command but it didn't help me.
kubectl -n bookinfo exec -it $(kubectl -n bookinfo get pod -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- sudo tcpdump dst port 9080  -A

kubectl -n bookinfo exec -it $(kubectl -n bookinfo get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"

istioctl version
client version: 1.8.0
control plane version: 1.7.4
data plane version: 1.7.4 (14 proxies)

Hi lads,
Received the same issue.
I can't check mTLS connection via istioctl.
Used 1.7.4 and 1.8 versions

Have the same issue, could you help?

Also facing with this issue. Looking forward for new information.

Also facing with this issue. Looking forward for new information.

cc: @esnible

+1 here. Trying to figure out how to ensure that mTLS connection is enabled.

+1 Facing a similar issue.

have the similar problem

Good point. I've just recently got same.

We are targetting restoring this information to the CLI in 1.9.  See https://github.com/istio/istio/issues/23776

@esnible How can I check mTLS mode STRICT now?
Thanks

I don't think it is possible to check with a simple command now.  There are workload settings and mesh settings.  I always have difficulty figuring out the settings.  See https://istio.io/latest/docs/tasks/security/authentication/authn-policy/ .  This is why the security working group is working on #23776 .

Is there a more current status on this ?

authors: AleksM-DA erSitzt esnible kmasi42 pmatv ppontus rvennam skolenkin sqerison tanzwut2525 vshynkar-rew


text:
External authorization fails when using an HTTPS ServiceEntry to a service outside the mesh

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
When attempting to use an authorization service external to the mesh, the authorization request fails with a 503 error and the following error in the sidecar debug logs:
2023-06-12T11:26:29.615719Z    debug    envoy router external/envoy/source/common/router/router.cc:1274    [C0][S481425681128483792] upstream reset: reset reason: connection termination, transport failure reason:     thread=24

The external authorization provider plugin looks like this:
      extensionProviders:
      - name: oauth2-proxy
        envoyExtAuthzHttp:
          service: "auth.mydomain.com"
          port: "443"
          includeRequestHeadersInCheck:
          - "authorization"
          - "cookie"
          - "x-forwarded-for"
          headersToUpstreamOnAllow:
          - "authorization"
          - "cookie"
          - "path"
          - "x-forwarded-id-token"
          - "x-forwarded-access-token"
          - "x-forwarded-refresh-token"
          - "x-forwarded-for"
          - "x-forwarded-user"
          - "x-forwarded-groups"
          - "x-forwarded-email"
          - "x-forwarded-preferred-username"
          headersToDownstreamOnDeny:
          - "content-type"
          - "set-cookie"
          headersToDownstreamOnAllow:
          - "x-forwarded-id-token"
          - "x-forwarded-access-token"
          - "x-forwarded-refresh-token"
          - "x-forwarded-for"
          - "x-forwarded-user"
          - "x-forwarded-groups"
          - "x-forwarded-email"
          - "x-forwarded-preferred-username"
          includeAdditionalHeadersInCheck:
            x-auth-request-redirect: "https://%REQ(:authority)%%REQ(x-envoy-original-path?:path)%"

And the ServiceEntry for the external service looks like this:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-authz-https
  namespace: i-istio-system
spec:
  hosts:
  - "auth.mydomain.com"
  location: MESH_EXTERNAL
  ports:
  - name: https
    number: 443
    protocol: HTTPS
  resolution: DNS

The cluster is definitely recognized and the request is directed to it as evidenced by these logs:
2023-06-12T11:26:29.613114Z    debug    envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130    shadow denied, matched policy istio-ext-authz-ns[t-tenant-main]-policy[nodejs-example-dev]-rule[0]    thread=2
2023-06-12T11:26:29.613125Z    debug    envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:167    no engine, allowed by default    thread=24
2023-06-12T11:26:29.613232Z    debug    envoy router external/envoy/source/common/router/router.cc:478    [C0][S481425681128483792] cluster 'outbound|443||auth.mydomain.com' match for URL '/secure'    thread=24

IMPORTANT NOTE: This is a single-stack IPv6 cluster. I went down a debug path where I discovered that ServiceEntries in single-stack IPv6 have a listener generated that listens on 0.0.0.0 instead of ::. I wrote an EnvoyFilter that updates the listener to :: which allowed proper resolution of the addresses inside of pods, but the auth continues to fail.
Version
$ istioctl version
client version: 1.16.1
control plane version: 1.17-dev
data plane version:  (36 proxies)

$ kubectl version --short
Client Version: v1.27.2
Kustomize Version: v5.0.1
Server Version: v1.27.1-eks-2f008fe

Additional Information
No response
Affected product area

[ ] Ambient
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Control Plane Revisions

This is likely sending plaintext over port 443. Youll need a DestinationRule to configure it to use TLS

@ajpauwels were you able to solve this?

@slice-arpits I was not :(

@howardjohn
Do you have any idea as to what could cause this?

authors: ajpauwels howardjohn slice-arpits


text:
I havent seen example or my own code that triggers OnHttpRequestBody

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
This is similar to issue #30213
While Im not the most familiar with the package I cant even get the expected response from the simplest use cases....The header and plugin stuff work fine, just getting a request body...
package main
import (
"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm"
"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types"
"github.com/tidwall/gjson"
)
func main() {
proxywasm.SetVMContext(&vmContext{})
}
const (
bufferOperationAppend  = "append"
bufferOperationPrepend = "prepend"
bufferOperationReplace = "replace"
)
type vmContext struct {
// Embed the default VM context here,
// so that we don't need to reimplement all the methods.
types.DefaultVMContext
}
type pluginContext struct {
// Embed the default plugin context here,
// so that we don't need to reimplement all the methods.
types.DefaultPluginContext
}
// Override types.DefaultVMContext.
func (*vmContext) NewPluginContext(contextID uint32) types.PluginContext {
return &pluginContext{}
}
// Override types.DefaultPluginContext.
func (ctx *pluginContext) NewHttpContext(contextID uint32) types.HttpContext {
return &payloadValidationContext{}
}
// payloadValidationContext implements types.HttpContext interface of proxy-wasm-go SDK.
type payloadValidationContext struct {
// Embed the default root http context here,
// so that we don't need to reimplement all the methods.
types.DefaultHttpContext
totalRequestBodySize int
}
// Override types.DefaultPluginContext.
//func (ctx *pluginContext) OnPluginStart(pluginConfigurationSize int) types.OnPluginStartStatus {
//	data, err := proxywasm.GetPluginConfiguration()
//	if err != nil {
//		proxywasm.LogCriticalf("error reading plugin configuration: %v", err)
//	}
//	return types.OnPluginStartStatusOK
//}
func (ctx *payloadValidationContext) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
proxywasm.LogInfo("OnHttpRequestHeaders")
contentType, err := proxywasm.GetHttpRequestHeader("content-type")
if err != nil || contentType != "application/json" {
// If the header doesn't have the expected content type, send a 403 response
if err := proxywasm.SendHttpResponse(403, nil, []byte("content-type must be provided"), -1); err != nil {
proxywasm.LogErrorf("failed to send the 403 response: %v", err)
}
// and terminates the further processing of this traffic by ActionPause.
return types.ActionPause
tinyGoEnvoyLog.txt
}

// ActionContinue lets the host continue processing the body.
return types.ActionContinue

}
func (ctx *payloadValidationContext) OnHttpRequestBody(bodySize int, endOfStream bool) types.Action {
proxywasm.LogInfo("OnHttpResponseBody")
ctx.totalRequestBodySize += bodySize
if !endOfStream {
// OnHttpRequestBody may be called each time a part of the body is received.
// Wait until we see the entire body.
return types.ActionPause
}
body, err := proxywasm.GetHttpRequestBody(0, ctx.totalRequestBodySize)
if err != nil {
	proxywasm.LogErrorf("failed to get request body: %v", err)
	return types.ActionContinue
}

if !validatePayload(body) {
	// If the validation fails, send the 403 response,
	if err := proxywasm.SendHttpResponse(403, nil, []byte("invalid payload"), -1); err != nil {
		proxywasm.LogErrorf("failed to send the 403 response: %v", err)
	}
	// and terminates this traffic.
	return types.ActionPause
}

return types.ActionContinue

}
// validatePayload validates the given json payload.
// Note that this function parses the json data by gjson, since TinyGo doesn't support encoding/json.
func validatePayload(body []byte) bool {
proxywasm.LogInfo("validatePayload")
if !gjson.ValidBytes(body) {
proxywasm.LogErrorf("body is not a valid json: %v", body)
return false
}
jsonData := gjson.ParseBytes(body)
// Do any validation on the json. Check if required keys exist here as an example.
for _, requiredKey := range []string{"id", "token"} {
	if !jsonData.Get(requiredKey).Exists() {
		proxywasm.LogErrorf("required key (%v) is missing: %v", requiredKey, jsonData)
		return false
	}
}

return true

}
Version
envoy:v1.24-latest
docker-compose
go 1.20.7

Additional Information
No response
Affected product area

[ ] Ambient
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[X] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Control Plane Revisions

How did you apply the WASM module?

authors: cecil-lireia hanxiaop