CREDEBL Weekly Community Call - 2026/09/16

Hi tip. Good evening. >> Good evening. >> I thought I got late today to join. I have very bad internet. We are on holidays. >> Wait for a couple of minutes for others to join. [clears throat] Okay, I think we can start. Maybe if someone can join, they can join later. Okay. There's nothing wrong with my Okay. Hello everyone. So >> hello. >> Good evening. Good afternoon. So welcome to credible community call. Uh we are running this call under um LFTT umbrella and uh it involves like participation of all the uh organizations competitors and uh we follow antitrust policy uh under which is under Linux foundation. So you can go and check it out. And also since this is a open community so everyone is welcome to contribute um to raise issues or to just consume it and uh share feedback. So let's have a quick um recap of the last week. Um maybe we'll have a look at the issues uh current states and u status of the PRs. So we'll start with it. Uh I think you are able to see the issues on the platforms side right? >> Yes. >> Okay. So um I think there is some work going on in the platform uh where u there are there is um one issue which was raised um which had uh all the um like just let me open there is an issue which is reported for the for vulnerabilities across all the 20 all the container ers uh this is uh this was raised by one of the uh organization which is consuming um uh credible. So I think um it it it was raised to AJ and he created this issue. So they mentioned about the containers as well that they are using like the uh docker images that u they have scanned and find it. So I think 98% of the um issues are related to the upstream uh packages uh which are either in um like the uh the the direct upstream or the packages which are used in under the um upstream packages. So uh I think we we had a discussion like u with yesterday and we divided we decided to divide it into further because there are so many like 300 plus vulnerabilities that they have reported. So we thought it is better to divide it into uh smaller uh issues for us to uh track it and um uh fix them in chunks at the earliest. Um is there any other thought on this or um I mean this is how we um we didn't waited for actually the today's call we just um thought of dividing it into further issues and um get it get started. Uh any thought on this or anything any other? >> So like uh so they mentioned like which tool they have used to identify this issue. >> Yes, we asked them they they used um AWS inspect. >> Okay. >> We usually use tree, right? We have >> we generally use TV. So we mentioned them about it. So they are using AWS inspect for it. I think they said they'll be on the call but they are not. So that's fine. It's okay. But what we thought is we'll fix the vulnerabilities because few uh like most of the vulnerabilities are also scanned in tree. So what we can do is we can fix it uh like uh they'll work with us. So we'll reassign some of them to like few of the members. And there is one member who has already shown interest. So we can assign it to him as well. Um so it will be easy for us to reassign these things to each other. >> Right. and we will scan using 3V and then they can take it forward and if there are any other um vulnerability found or any other issue then they can raise the uh issue here. >> Okay. So you can go to okay there are other of like this is the other sub issues which are created 50 to 58 and uh we are tracking the progress of it as well. If you can see most of them are in the nads and verifier like most most of them are in the nests and ns downstream images. So please feel free to assign it to yourself or if you want to discuss this we can have. So in this is there any segregation of issues related to code or uh like can we separate out somehow the vulnerability related to uh code? Um yeah I think we can separate them based on the images. Currently they are separated based on the severity. >> Mhm. Right. >> High, low, medium. These three severities um based on these uh three severities we have created the issues critical, medium, low. Uh but I think there are services which are there. So we can create different different issues small issues as well. >> Mhm. >> Or maybe raise small PRs. For example, one for credroller just fix it and merge it and close it. That is Yeah, that is also a good idea. >> Yes. So most of are related to the packages correct? We have to upgrade the packages and >> yes most of them are related to package upgrades. >> Okay. >> And fixes are available for 98 99% of the uh issues. There are few issues for those fixes are not available. We have to accept them as u known vulnerabilities for now accepted risk. >> Okay. >> For example, this these are all npm packages and OS images only. So this is all about platform think. Okay. Medicare project. Uh we have to submit report. There [clears throat] are few issues which are uh few issues which are opened by Mark from 19 sign foundation. Um one of them related to agent provisioning um which tested by M and Sah there are there was an issue related to the config file I think he has fixed it I'll retest it me and S will retest it again and just comment it if that that is fine then we'll uh close this PR and I think after this we'll test holder isolation and agent routing as well. Any other update from anyone on platform side? >> Uh yes ma'am. So recently we uh fixed one issue uh which is related to sending the OP invitation uh related part uh when we sending the uh OP invitation or is insurance invitations or verification invitation. So for that we uh uh fetching the latest uh connection invitation from the table. Instead of that uh sorry uh we fetching the last uh invitation instead of that we need to fetch the latest uh invitation uh for the sending the OB invitation OB is insurance and the OB verification as well. So I have made changes for the uh issuance uh and uh for the verification I will uh do the changes and push the uh code into same uh branch. >> Hello. >> Okay. >> Yep. That is the update. >> Okay. This is for issuance that you have done. So same thing. >> Yes. Same thing we need to do for the verification as well. >> Once you push, we'll just merge it and >> yes, >> I think we should uh think something uh concrete about it because like uh there are multiple invitation from the same agent in the database, right? >> Yes. Correct. >> Yeah. So I think we should change the approach only the latest invitation that is used in the uh uh UI that should be in the database only. >> Yeah. From the UI point of view maybe we can change the approach >> I think in the database >> instead of generating the new invitation. And I think what is saying that we have to we should think and check if we really need multiple invitations to be created. >> All right. >> Again and again. >> Yes. >> Yes. Right. [clears throat] >> Got it. This I'm just creating a um issue so that we won't miss it. Yes. uh multi-use. I think multi-use connection invitation we can create and just um use it. Let's give it a thought on this for sometime. Maybe we'll discuss it in the next call if needed. >> Yes. Um, anything else? Uh, from anyone tu or [clears throat] >> Yeah. Uh, from my side like uh we're trying to merge a few services uh like uh there are m like 18 services in credible. So like we're trying to reduce that. So uh so we merge web hook into organization web hook x9 and we converted utility service as a uh library. >> Mhm. >> So so I've raised the PR for that but there are few dh related issue. So like I need to fix that. >> Okay. This one services. add checklist. >> So which all services are merged in this expanded coverage? Uh we have uh merge web hook uh into organization uh xy 9 x9 uh into organization agent uh provisioning into agent and uh we removed the utility service and created a separate uh package for that and used uh use it internally. >> I think there was an issue right you have to link this PR to the issue. >> Yes. Uh yes, issue number uh uh let me issue number 17 uh2. I've linked this PR here. >> Okay, thank you. Um, anything else? So, we can move on. >> Nothing from myself. So I think on agent controller there are some PRs which are to bump the uh uh version and there is one PR to add optional open B transit KM AMS withholder key routing. I haven't looked at this PR. We have to check. I think he has added open bow KMS back end that is as an optional KMS in the controller. Currently we have escer so made it configurable. Oh interesting game. No, no, no. I'm just thinking we'll need some configuration in uh uh platform as well, right? For setting this KMS policy. >> Yeah, I think it should be driven by the platform config. Yeah, because all the other things are coming from like this config file is created from um platform. So the required changes to configure open bow as a KMS while spinning up the agent should come from uh platform. So there may be some changes required in the platform as well for the same disper and I think there is no issue going on there is no issue for this I think no this is for status list allocation Okay. >> Uh, can you share this link on the chat? >> Yes. >> Yeah. Okay, we'll add a comment here and review it. Apart from that, I think all the issues are uh version bumping the version. We'll check this. I think [snorts] Rohit, can you check this one? >> Yes. >> There is no there was some missing variable key and he has add so that we can merge it. >> Yep. any other update from on controller from anyone? >> No, nothing from >> same. Nothing from your mobile SDK. the moonstone scripts as well. Uh studio there is not no not much update on studio side. We are not not currently active on studio and upgrading the features on studio. Um >> but I was doing some uh dependencies upgrades here a PR but uh we'll end up opening a PR. Yeah, I think most of them are dependency upgrades. >> I think we can take these at once and test the workflow because after the upgrades you have to test everything. >> Yeah. >> Okay. Some of them are minor ones like releases but yeah there are there are few which are kind of major upgrades >> like this and uh I think we will be able to combine the pull request into one one PR and Uh, open that up and close all of these. >> Okay. >> What do you suggest? >> Yes. >> Maybe I if the PRs are already raised, we can just um merge them and close. >> Yeah, optionally we can do that. Yeah. And um um going forward we can we already have uh like u batching the dependabot updates but we can look at it and batch them again to have patch upgrades smaller up upgrades in one. >> Yeah. I we can assign it to ourself and test it right and [snorts] then there was one for the bun support. Uh so now since we have 1.4 41 release in Rust. Uh I think that can be taken up not not in this studio no repo but uh I think we had initiated in the controller first I guess. >> Yes it is in controller and u this as well here also we have one. Yeah. >> And uh controller and platform >> right. >> So we can start from one of the repositories. Um do you suggest starting from studio only? >> Yeah, I think uh that would be less uh destructive. >> Yes. And we can test the latest update of one as well. Yeah. We have been using one 1.4 in other projects. Uh so I haven't seen any issue so far. >> Okay. >> On 1.4.2. >> Okay. 1.4.2, right? >> Yes. Let's clean up the old PRs once we I'll have a look at it and clean it. Okay. Any other update on studio? Then we can move on to mobile SDK and have quick updates. I think. >> Okay. Uh on mobile SDK side. >> Okay. There are all only two PRs for the version bump. >> When you go to the release section, releases here. Uh last week I made a release uh by fixing some of these like high severity depths. >> Okay. >> Uh we have to test this SDK. Um right? >> Yeah, we have to test this after the release. [snorts] >> Okay. Maybe this should be a alpha release first. I guess >> I think this is released as 2.2.1 directly. >> Yeah, >> there is 2.2.0 also which is released. >> That was long back I think in the month of May. >> No, no, it is last week only. There are two releases 2.2.0 and one. >> Yeah, I think u with some minor changes I guess. Uh, okay. Do I make them alpha release? Um, Amit, can you make this change to make this as an alpha release? [snorts] >> Okay. because uh alpha release will automatically like executed once we merge on the main branch. Last week aer had mer some PR. So the new release will be executed. >> I think but these >> let's let's do like this like let's test the SDK first and if we find any breaking thing then we can mark this as an alpha release. If everything works, I think uh we can live with it like >> okay so like what we have to do on the SDK side so like do we need to have a separate release or that is already done release is done we have to test with uh some uh app either with so view or reference Sure. We'll so in the sio wallet [music] we'll upgrade the SDK package and we'll have to do the end to end test. >> Yeah. There is one good first issue to this. Okay, I think uh that's it. Any other uh update from anyone? These are all old issues and PRs which are >> yeah from the milestones uh perspective in the platform repo we have a project which uh which defines milestones. So we have defined a milestone for September 30th to target some of the security hardening and uh primarily the dependency fixes depending on the severity mainly the critical ones and all that. So >> I think we'll have to >> is it in road map or uh >> um it's not in the road map. >> Okay, in the in platform. Uh if you open any of the issues or PRs, you can find the >> okay. Yeah. >> Yeah. That is Q3. >> Okay. >> So depending on the progress on each of the issues or PRs, we can mark um that particular issue or PR to be part of this milestone. So we are planning to make a release in 15 days. Uh yes and there was one suggestion from um uh TU uh I think we discussed that u we have divided these vulnerabilities as critical low medium right we can further divide them based on the service as well so that it will be easy for us to close the smaller smaller chunk and release for example uh here in I think it is not mentioned here >> because uh if the report the reporting of the vulnerabilities is not based on the service that's why it is based on the images because the tools that we are scanning are running on the images. >> Yeah. Image as in um like images of the service, right? >> Yeah. So it's a it's it's the same thing then if it is image in service it's the same thing now. >> Yes. So if there are multiple issues in the let's say in agent service um so we can create one PR just for agent service and merge that PR first and release it. So, so that's how that would I think that would increase uh because there were a number of images under hub and verifier that would increase the issues in in GitHub. Uh yes. >> So our focus is on severity whether irrespective of the service >> focus is on the severity the critical uh high and medium. >> Yeah we will not create the issue but we can choose to create PRs for just for let's say credroller. So all the 28 issues are fixed. Yeah, that anyway. >> Correct. Correct. That anyway for each of the sub issue uh we have that breakup. >> Yes. >> But then you know when you open up a PR for this sub issue like 1754 you would typically fix all the critical ones right in this >> this issue is meant for critical. >> Yes. >> We'll end up fixing all 68. No, >> which will impact all four five images, >> right? >> Positively [clears throat] >> but then credo controller v 2.2 image is also part of some other sub issue which which is meant for low priority low severity. So if we list images based on the uh sorry if we list you know segregate this work based on the image we end up clubbing all the severities then the focus is not on the severity the focus is on the image the service >> okay >> so we want to do it in a priority of the severity Okay, we'll keep it the way it is. >> Yeah. >> See how we want to fix Okay. Um, I think that's it. Um, is there anything else to discuss? Uh, I'll create a wiki page for today's discussion. Uh, please feel free to add uh the points there. All right. Thank you. >> If there is nothing, we can meet the next call. >> Yes. >> Yep. >> Thank you everyone. >> Bye-bye. >> Thank you. Bye.