OpenSSF Scorecards Biweekly, 2 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Scorecards Biweekly Sync (June 2, 2022)

Description

https://github.com/ossf/scorecard#connect-with-the-scorecards-community

A

Hi, I'm back, can you hear me? Yes, I can yes, I'm unable to share my my screen. The audio is disabled by zoom automatically and I don't know how to put it back on.

B

I can share the screen if you want, um we can call that.

A

B

Sorry, I said you, let me know where you want to scroll down yeah.

A

I guess I guess that's fine. The agenda is pretty it's pretty short, so I guess let's start um yeah welcome everyone to the scorecard bi-weekly meeting 2nd of june.

A

If you haven't already done so, please add your name to the list of attendees.

A

Is there anyone today who's new to this meeting and would like to say hi or where they come from.

C

Yeah so hi everyone. This is sripad sripad margara, I'm a synthetic staff member at ibm research, I'm getting some initiatives around supply, chain security, and uh I am big fan of scorecard I've been using it for uh for a while, and uh I would like to share some uh work that I've been doing and see if how it aligns with scotland, so yeah, okay,.

A

Yeah welcome and great to have you here. Thanks?

A

Is there anyone else, who's new to the meeting.

D

Yep, hello, everyone, I'm sebastian crane, I'm coming from the spdx angle, with software builder materials as a focus, but I'm intrigued to see what this working group is all about.

A

Cool welcome sebastian.

E

Hi, I'm caroline um I've been working with sripod, I'm also with ibm, um I'm a security engineer and yeah. I attended last week last meeting, um but I was just a lurker. I didn't say anything so welcome.

A

Yeah welcome back.

E

A

A

I guess that's it then so uh cool well uh great to have more people on board.

A

I think so I I think you know this meeting is about scorecard and I think most of you have heard about scorecards.

A

We typically discuss you know technical problems, project updates and directions about where we want the scorecard project uh to move forward to so that's kind of what we do in this meeting.

A

um I think uh let's proceed with the announcement uh jeff. Do you want to say a few words on um what you wrote and then I think after that we can. Let sripad talk about the work that he he wants to talk about.

F

Yeah, just quick updates, not discussion items and if you can click on the first one they're, both there on the readme, so allstar has a couple new features for configuration.

F

um The first one here is that you can put org level config I mean you can put repo level config in the org centralized repository if you create a subdirectory with the um repo name and this the second one here is that you can also have a central config and then in an org level. Config like you, have multiple orgs. You can have them all point to one central config by using this base, config option.

F

So just some two functional changes. There are functional additions.

A

Cool any question for jeff.

A

All right no question, so uh I added a point on the scorecard action release we released last week, version 1.1.0.

A

The main functionality we added was the support for the github token, which is the ephemeral token that github workflows can run with this way. Users don't need to to create a path, an authentication token.

A

This was a request from many of the users, so we we added support for this.

A

It comes with a caveat which is that the branch protection check doesn't work with this token, and this is something that github is aware of, and they are trying to uh to fix it on their side. So as soon as they fix it, we'll have support. We will, we can add, support back for the branch protection settings.

F

Is there any anything to say about the 430431 announcement? I know that's nuisance last time.

A

um I think this is just the release we made with a bunch of fixes uh and that's what we use in the action release. So I think those other changes uh I don't know naveen azim. Are there other important changes yeah there.

B

Are some obviously there's some breaking changes I mean like we are. We are stopping the old json format and that's that's. That's in the release notes to say warning. Those are breaking changes, uh but that's one critical thing: people are looking at the v1 json formulators out and that's not being supported going forward and it was already mentioned during the week too. If I'm not wrong, so that's one thing: that's that's there.

A

Cool thanks all right, maybe another announcement that I forgot to write down in the in the notes is that um we have someone uh interning at google, who is going to be working on uh a way to run scorecard on the dependencies of a project.

A

We don't have a design dock, yet we will share it once we have it.

A

I think the idea right now is to add support inside the scorecard action and when you have when there is a pull request from depend about renovatebot or any pull request that changes one of the dependencies, we would be able to show the user uh the the the scorecard results for that dependency, so they can learn and get. uh You know used to seeing the the results and maybe take decision based on on the results.

B

um So I have a question on this, um so I know the the design that needs to come in, but the general overview is it going to be using bigquery to fetch the data or like? Where is the direction for that? Specifically, for that repository like for that, um and I we don't have- we don't have commissions in our scorecard for two specific ones. How is that going to go? Pull that specific version or feature of the dependency.

A

Yeah a great case, great question, so another problem there is is also like the mapping between a package name to a project repository.

A

So I think we're going to keep it simple for the first iteration, which is, we are just going to get the the package. Names, maybe focus on golang and then we're going to pull bigquery data ahead. So just show the latest results for the for the project.

A

I think people who update tend to use some of the some of the most recent uh versions anyway um yeah. So I think that's the plan to keep it simple and over time when we have better support for commit version. We'll try to add that.

B

um And also, I know I'm jumping ahead. Why keep it part of school got action, because now that ties with the scorecard release? So if we have to make any changes, this would be like I'm just talking like how I'll get update. They have the dependency review as a separate action and dependency dependency feature as a separate one. So now they can have independent releases and don't have to step on each other. The example, if there's a set fault or any of that, then we need to release this and cause problems to the other one.

B

So is there a specific reason to keep it within the scorecard action? Can it be like how um how um codeql has multiple actions within the same repository? I'm not saying that we need to create another apostrophe.

B

Can we have another action within the scorecard actions repository, so we can have those releases go separately and still don't have to step on each other.

A

So I guess um this is still uh to be discussed right. I'm just gonna say what what I have in mind and I guess everyone else can can chime in.

A

I think the idea of using scorecard action is that it in terms of usability for users, it's just a single dependency, and so once like, we have already a thousand projects that use scorecard. So if we add support, they will automatically, you know see the changes.

A

um I think, even if you had two different actions, if a user wants to to have both either way, they'll have to update when you update. So from their point of view, I think having one is is simpler. um Well, that's kind of my my point of view right now, but, like so.

B

Can I sorry I don't mean to check um instead of doing a design dot? Can we just write down what, like whatever we discuss right now? Can there be just a github issue, so it's easier to discuss over there, or at least asynchronously like so that we don't have to uh like somebody works at design dark and then don't even know what features we're going to talk about that.

A

Yeah, I I think, by design dock, I I meant mostly like one page and put it in the in an issue or a discussion. Yeah we'll definitely do this right right now. We don't have anything so as soon as we have some like rough ideas about where the project can go and like what is the first step, um I think we will create an issue I think, like maybe next week.

A

Does that sound good? Thank you.

A

Are there any other questions about this project.

A

Okay, so if there's no more questions, let's move on to the open issues, uh I think uh sripad floor is yours.

C

Yeah, thank you and do this I mean I don't know about. I need to read more about this particular project that you're talking about, but it sounds pretty related to what I'm going to uh share. So let me see how I can share this.

B

I want to start my share so sweetheart. You can probably share the screen. Okay,.

C

Yeah, do you see the ppt presentation? Okay, so this is a project gauge right, so it's just the name that I gave it's around recommendation for oss dependency and before I start so this this is open source. It's available.

C

Again, the way it started it and every project start somewhere right, so it started with the earlier this year. We had this. uh uh Everyone know this npm, uh malicious npm packages with colors and figures that break a lot of applications and that that's when you essentially, we started to check right. Okay, if there was a malicious maintainer who was able to push some changes, why did I ended up automatically updating my dependency? How did it had no way to basically check uh before updating had any indications of those?

C

And yes, we had a lot of discussions that the dependencies we are not paying to specific versions and everything, but even if the dependencies have been did I had all the tools and all the basically data available to make some informed decision and the answer is: there is no control way to update dependency virtuals right when I want to update from version x to version y, I don't know uh if, for all the changes, all the pull requests that went into this release are the best package will follow right and what kinds and size of changes that went into his release and we can go into like kinds and size and how we can determine it.

C

But the bottom line is: can we identify and collect some indications of some bad behavior and we can get some change in sites like when we see any changes? Can we get more insight into what kind of changes are this and that's essentially, uh when I started uh looking into this and obviously the first start is still okay with the new scorecard, uh which gives us essentially point in time. uh Evaluation of uh these practices, right, like price production, is on peer reviews are enabled.

C

uh If I run it, I can pass those checks, but you, if I'm a really malicious maintainer, I can disable this. I can push some commit changes, enable them back enable this setting back, and when I run it again, I get all these uh checks getting passed right, so we uh just call it temporal loss because we are not essentially able to maintain this uh capture this. uh This setting changes over this time period, and this is primarily because it's not limited of scorecard github or any scm.

C

They do not maintain this immutable record of setting changes like when I make a pr or when I commit something I get immutable record like this is a commit, but that is not available with github. For when I change the setting right, there is no immutable record, that's one thing, but they provide uh the immutable record of the code changes or when I cut a release whenever you make a new release so that information is available.

C

So can we use that information right and second, is? If we are executing this scans against the repository? We execute it against the main or head branch right and let's say we see this particular uh head branch has a vulnerability, but if I'm using maybe a previous version where the dependency is not captured, then that uh I cannot map that execution that result to my application or my use of that particular uh repository or that particular package right so in case.

C

uh What uh basically I started looking into is into releases like when we have any package release it has commits. It has pull requests, every pull request every commit, they have labels, they have link issues, they have their labels. We have contributors, reviewers release, notes signatures right. All these data is there available for us, and this is predictable data immutable records.

C

We have insights like who are top contributors, how many lines have been added or deleted? So can we curate this and provide some actionable insights? What what changes are going into this releases and uh that's essentially the primary objective? So let me quickly show you demo so the way it can be run. Essentially, you said this is the it's again it's uh motivated by the the scorecard. So it follows the similar notation. So it says it has two modes: one is the package uh where it runs again.

C

Individual packages and another is sbob where it passes, there's bomb and uh does the same thing for all the packages in this form right so for packages. So this is the flash package. Let's actually first, let me we can run it against core card right. So this is a scorecard project. This is the repository uh where this particular project is hosted.

C

If we run it- and this is, the t is a tag right. This is the current version that I'm using, so what gauge is essentially in the backend is doing. It is making api queries to this particular repository and collecting all that information that I just mentioned. So in that there were two challenges, one challenge primarily right, so some of the information that we wanted to collect it was not available through the github api like go client yeah, so we have to have the mix of uh graphql api and the go client.

C

So, for instance, give me all the comments between those these two uh pr or these two releases. That has to be a draft ql query. So there's a mix of this, hopefully it should finish. First, let me show you the previous.

C

Okay, so this is kind of report it produces right. It says the current version is four to zero. The latest is this one: uh two, you are lagging by two releases because they are totally between or 21 days, because some organizations they have the requirement that they cannot like be in more than three major versions or more than 180 days right, and these are the federal clients that I I had talked to. They said they have this requirement and, more importantly, if we can, it basically recommends okay, you can go and update to this version.

C

E

C

Unique contributors who contributed for all the prs that went into this particular release: they were reviewed by six reviewer, unique reviewer and in some cases I found that the person who is making a pull request. He is the one who is reviewing the or approving that particular change. So we check that these are non-peer review changes. That means it is reviewed by the one who is not actually committing the uh change and making a pull request, and there are zombie commits.

C

I mean this is this is again for lack of a better word, so these are commits that are made directly to the main branch without any pull request right. So uh no pull request, nothing directly, change to the main drag and then, as I said this, this is this- gives us some insight and then what kinds of changes right. So we look into right now we are only looking to labels uh of pull request, issues associated issues and everything, so that at least gives us some insight into what kind of changes are going into it.

C

Like some dependencies that change some data actions, uh some bug fixes went into it uh so this. Actually I mean this is again pretty naive data, but the idea essentially is to use this data and give some build some models that can give some actionable insights.

C

So this essentially again when I run it against the uh one of the popular one which is tensorflow right. It tells us that there are a lot of commits that went directly into the main branch. Then what kinds of changes went into it or what components were affected? So you can see it says: core core component uh has been changed.

C

uh What kinds of changes went into it large extra small? So these are the components that are changed so now, if I'm a user of this particular library, and when I see a new version, I said okay, these are components that are changed and should I update, I can make an informed decisions before updating making a update right.

C

Similarly flask. This is uh another very popular package which says all the commits they are going into the main branch right without any pull request, but the kinds they are like talk, testing typing so seems like okay right. These are changes to ready me, probably some typo, but uh still it gives us some indications of flags and some red warning to look into it more closely.

C

So that's essentially is the so that's. This is the first proposal right so can we have this support in scorecard to score releases right, so we can come up with some meta click and how part we can maybe take later.

C

But first thing is: can we have this as uh in addition to scoring the policy, we can also go and score individual releases and add this support and add some more checks there and the second is: uh if you look into the overall oss ecosystem right, it has a lot of currencies like it has source code. It has registries, it has catalogs open source catalogs like artifactory marketplace, rectangle registry, like osi, oci images and even for source code. We are application report data from our infrastructure report deployment manifest.

C

Can we again uh extend the scope and add the checks for these kinds of artifacts? When we scan a repository we see there are terraform, I mean most of the checks are going to be common, like branch protections, reviewers maintainers, but uh some other specific, like in app repo, will look into oss fuzzing vulnerabilities.

C

So, for if we see there are uh data format and civil repository, we can use checks like tfsaf to see if there are any terraform uh scanning that needs to be done. If we see this is a helm chart, there are hem types in the repo. We can automatically run some cis checks against them. Similarly, for oci images, so that's essentially a second that can be added support for this different kinds of oss artifact to scorecard uh yeah. That's pretty much what I had so any thoughts, any questions, feedback.

A

Yeah thanks a lot for the presentation. That's super interesting uh who would like to start with a question.

B

I would like to I have one before I give comments. I have one question on that on your zombie comments. um So, were you able to check whether your zombie comments match with what scorecard is showing um like you see? There are 15 zombie comments, 122 zombie comments on your like on on flask and tensorflow. Were you able, because usually these this information is available within scorecard, at least in the big query? It clearly shows how many of them don't have this data. Were you able to confirm it's not.

B

We are doubting your answer. We want to make sure whether the data that we are pulling is also like. We just want to make sure whether data is right. That's that's! That's what I'm trying to check.

C

Yeah, so that's a good point, so how can I I can definitely go and check it uh in the big data.

B

Yeah it's available. All the information is available, so you should be able to get that. So that would be good to good point to check whether yeah um yeah.

G

B

You're building something to get that um um yeah absolutely and that's one thing that I have yeah specifically.

C

Yeah yeah, I I'm going to generating out of it.

B

um Yeah, I want to wait for others to talk about the rest of the stuff, but I do have some opinion on the on your proposal, but I'll let others talk before I go thanks thanks great.

A

Who else want to uh to go next.

G

um I I can, I just had some questions so on your second proposal. uh Could you just uh like reiterate what uh what do you mean by different kinds of particular artifacts? I I wasn't sure if it meant different repositories like apart from github or are these uh something like you know like we checked docker file today, but you also want to check some other types of uh artifacts on our github repositories.

C

Yeah exactly so, it's not different like github gateway, git lab and everything, but even if we look at just github right, uh people are using it to host their application code like the packages also the infrastructure code, like ncbi data form or cross plane and all those new infrastructure code that is also being available in the on the github repositories and also help charts right. If you look into all the operators and everything all so there are this, that's why I just call it currency, so different, granularities or different types of artifacts are available.

C

So when we let's say someone gives me a repository, this is the repository, and can you rate this or score this for me, so we can look into some settings like transactions and everything, and now we can go and see what kinds of artifacts are. If it is application source code like dot phi and dot go, we can just run the scorecard that we have today right.

C

If we see there are terraform dot, tf or ncbl scripts, we can run different kinds of checks uh like tfsec or others that look into whether there are any misconfigurations in the terraform or missing configurations. It is the deployment manifest like hen chart, so we can run some ci checks like cube, linker or others. So we have contributed some checks to tube enter uh the ci that perform the cigs.

C

So then we can have the holistic assessment of repository right so which it can be any kind of reposition. Similarly, images uh either way, we can basically score images also. So if I'm using some base image or any image any open source image, can I score it in some way.

G

Right so um so yeah I'll, try and answer this in two parts. So I think uh the images thing is a bit difficult for scorecard, because I I think it's uh it is hard to, because scorecard is written with the assumption that we'll be running it on a repository, whether it's github or a gitlab type of repository. So it's usually hard to have that mapping of like image versus code directly.

G

So that's probably not a problem. We are trying to solve right now. However, uh I do like the idea of doing the terraform or the ansible uh conflicts that you mentioned. I I'm personally not too familiar with this, uh but the idea definitely fits very well with what scorecard is trying to do. In fact, this is how we kind of extended our pin dependency check over time, so it started with a docker file.

G

But now it also looks like you know, other types of files, so um it's overall on a very high level seems like a good fit, uh but definitely we should discuss more. So I I would for that part from my side. I would suggest um let's, let's open a github issue on scorecard. uh If you could, just let's say, have a very brief few line proposal right like let's say we start with the terraform file.

G

If that's what we want to start with, uh if you could just tell you know what kind of checks uh or like what kind of security aspects you want to look for and how you want to implement it, maybe we can discuss it there, uh yeah, absolutely yeah I'll hold my thoughts on the other proposal for now, just just in case. Anyone else wants to write their ideas.

G

B

Lauren, do you want to talk, or I have cop tattoo.

A

B

I'm going to tap on the second proposal that um mentioned same as you mentioned,.

B

Correct me, if I'm wrong, this is almost like running security tools based on specific kind of code like star form, I'll, write, df, saying if it's go code, gosek tools like if python there's some python xyz tool like different linters security tools to run on different kind of code, um is that the proposal talking a thousand foot overview, not.

C

Yeah, so not uh yeah, basically kind types of artifact right like so, we can even go like go, go, seek and everything, but more at more granular. We can look into like we've categorized all those into app application code uh that that are. There are some checks which are common for application code because and some checks which are common for like infrastructure. There are formats, because if you look into this category, they are managed and operated in a different ways. Right.

C

If you look into a app code, it is changed a lot of lot frequently than ansible or terraform core right. So the idea essentially to have this at a little more granule, a coarse level not very even like if it is a fire and this if it is a core and goes thing even we can go that level also, but in this one I just think if we can have it at least support for uh this uh at course, level. Like it's infrastructure reports, uh deployment, manufacturing products in charter uh sure we can.

B

So, let's, let's assume, if it's infrastructure report, let's assume it's a mono republic infrastructure? Oh, let's keep it simple if it interests your repo yeah, let's see suppose we found the stereo styrofoam files, so is your recommendation that we run tfsec on the on the on that repository along with existing scorecard checks and add that additional score into scorecard results so that, if somebody's going to consume that understands as a scorecard repository, we understand what these existing scores are. Along with that here are things that tfc complained about.

C

Exactly so, if you look into today's right, so when you see the score card, it runs. If you see is the it does uh oss file, it does vulnerability scanning, it tells uh the pinning pin whether dependencies are pin or not. These are checked for application reports right.

C

They are probably not applicable for infrastructure bacteria form, so for them there can be different set of checks that can be done uh so based on the type we can apply, different sets of checks uh on that and some of the checks they are going to be common right, which are the repository scheduling, checks so yeah. I.

B

I I like you mentioning that app like fuzzing, does not apply to like infrastructure repositories hellhound chart, because lots of people are using different stuff. So initially initially, I brought this thought process that, but then we decided some time before scorecards not into scorecard was generally essentially wasn't in this in this space. But I'm more than happy um it's a good thought process, but we got to be specific as to where we draw a line, but I do agree to what azim mentioned.

B

um We got to think about this um thanks and I'm working here, um and I do have your that bras on the first one. um I want to say I like the thought process. The release would certainly help if that can go into scorecard, but understanding what release is in. How often that is run is an implementation detail that we got to think about.

C

Yeah, absolutely, I think, how part we can maybe go later like what exactly goes into it and uh this but yeah just in the first. I just wanted to get this feedback right like if max is uh and yeah.

B

Thanks um thanks lauren.

A

Azim, do you want to? uh I think I think you had other other questions.

C

No, no, so uh uh I just so. You want me to open the the issue for both the proposals and then we can start on discussion there. I'll just put some details.

G

And uh yeah, I think, that'll be helpful. I I definitely think the release one needs a bit more thought it might, like. You said work well with lauren's proposal uh to have a dependency check, but yeah.

E

G

Definitely think about how to do that, but the second one should be more simple, depending on what what kind of security checks you want to add um so yeah we can tackle that first.

C

Okay, yeah sounds good all right I'll. Do that.

A

Okay, so something I wanted to add is, um I think, some work that azim and- and I are doing around the scorecard badges we're going to be recording every the scorecard results for every commit, so that you might be able to use that data to to like, uh like for the the release, uh the release, information, yeah.

G

A

So I don't know what the time frame is for this. um I don't know azim. Do you have any rough estimate.

G

um Yeah- let's say I we are hoping for the end of this quarter. So, let's say uh conservatively, maybe like mid july. uh We can. We can name for that, but yeah uh we can think about how to like yeah scorecard like lauren says. Koka does also support uh commitsha based thing, so we have thought about the similar problem that you mentioned, that you know scorecard shouldn't only be running at head, but you should also be able to look back, but we don't support versions in the sense that we don't understand a release version.

G

What we understand is a commit shot. So if there's any way to map a release version to commit sha, I think it should be possible to look up the scorecard results for that show and figure it out.

C

Yeah, so I think in this one what we are trying to do is we are trying to aggregate the all commits in that goes into release right. So if we have that support that, if we have scorecard results for individual sha, we can basically say okay in this between these two release. These are all the commits. Then these are their scores right. Then we can get some insights into it right.

C

B

Force, sorry, let me do it. That's a fire hose of all commits scorecard ones on an on a scheduled time frame because it doesn't run between two releases. If you, if that's what you're trying to do.

C

No, no, we want, we don't want to run it. We just said I I want to basically have these two. I have two releases. These are commits, that's what we are doing right now like we are not running scorecard from all the shock, but we are saying between these two commits. Are these two releases? These are all the pr that went into it. Let me get some insight into whether they were reviewed uh and uh what kinds of changes with their uh and what were their labels.

C

So we can get some more insights into what went into this relations right, so I can make. When I want to update, I can make more informed decisions, whether I should be updating this previous version or not.

B

All right, let me do high check uh interject assumes conversations include.

G

No, no, I I think that's that's pretty much it um yeah. We can discuss more. I I think this. This definitely needs a bit more thought uh we can discuss that. Often. Thank you.

C

Yeah yeah, thank you.

A

Sorry so there's a yeah thanks uh sripat for the the presentation. uh I hope we can. We can work together, uh starting with the issue.

C

Yeah absolutely yeah yeah.

A

So I see someone added another point about discuss about dependencies with the tool chain, uh I'm not sure who added this yeah. I.

B

Added that sorry, I added that. Okay, I want to show my screen again just to make sure okay, um the the problem right now with scorecard, is like I specifically I'm bringing these two up like I'll open up these two issues.

B

Scorecard scorecard um for people who don't know scorecard has two gomad um oneness for the main repo another one: the tools, repo tools, reports, where we depend on a bunch of different tools. uh We want to pin by specific sha so that we know which version of the tools that we're using and that is growing, really large, especially bringing cosine in um and and I'm working on, two pr's one is there's a there's: a high vulnerability on gotof, which we don't directly consume.

B

It's our tools, dependency that consumes that's one, that's one problem and I'm also working on another pr that is trying to upgrade to go 1.18 and put these up. Both these were blocked by the co-dependency and um jason was pretty cool. He immediately tried to fix this problem, but it is growing into the moment.

B

Like long story, short cool had a dependency with cosine and cosine does not do semvers and they broke their dependency, and that's why co was broken and um we use co and cosign and that could that cause collisions for the problem. So I asked jason from who right now works for um uh who also works in a six store and in co to help me with this, and he went ahead and helped with that, but still in spite of that, there are a lot of conflicts in dependencies.

B

The two reasons that I'm bringing this up is: we are trying to bring in the scorecard action repository into scorecard, and all of this is I'm still having a hard time trying to solve this problem like co-dependencies uh are especially we have. We have. We have replays options, um I'm specifically talking about these replays option, I'm going to share the screen right now.

B

um If I go to tools my godad mod, there are a bunch of replays options purely for vulnerabilities that we do, and even if I remove these replace options and if I try to try to get the main like what jason mentioned still doesn't still doesn't work, there's a bunch of errors and bunch of problems.

B

Two issues in this specifically, we are treating that one is I'm still working on it. I don't know how far we'll proceed to work on this second option and second, second, concern is, if we bring in school card action into this, um like what stephen mentioned and stephen also ran into the same problem. It's going to create a lot more issues, and I just want to bring this up over here so that we think about that, um and I want to open up for others to have any conversation on this.

G

uh I mean I'm okay holding off on like doing the merge. I mean. That's, that's the concern here. I don't think that's a high priority. Okay,.

H

Yeah yeah, not you want to see some emergency on your concerns here. No.

B

No one is mostly concerned. Another one is my concern. Is bringing action in because go? Has these problems that that is causing these dependency collisions that are having a lot more and are maintenance of.

G

Yeah, when I said merge, I meant like the merge of scorecard action and scorecard okay, if yeah. If that's that's a concern yeah, I I'm I'm okay holding off on that like I, I don't think that is high priority at all, uh at least from my side, and I believe even laurent uh is okay holding off on it. uh If stephen uh hey, I don't think he's on the call right now, but if stephen is interested in doing it, we can have a conversation institution but yeah.

H

That's the only.

B

Concern we can hold off on it: okay, you're right, that's my only concern because uh yeah, that's my only concern um and probably again to solve this okay, especially um to solve this particular the gotav and the go a 1.18 we might I'm like, like I'm gonna, try and see if we can plot co and we don't use, we use cool only right now we use co within our. um We install co within the action. We probably have to do that, but um I would work through that.

B

But that's that's something that you want to give an update on where I am right now on that thanks.

A

Yeah, I think, navin, you answered my question. My question was more like: why do we need to compile co ourselves like? Why is it part of our goal.some, because it's just something we need to pull the binary for. I guess yes,.

E

Like whatever we.

A

B

A

Why is it in our go module? Okay,.

B

Let me let me answer that question specifically, so we want to know what specific version of tools we do like. We want to be sure and that's why we have these underscore imports so that we know what version of the tools that we have and we can have. Reproducible builds based on the version of the tools that we do and that's why we have them the tools and that's why we have got our model prototype. To answer your specific question um now you're, similar to what you mentioned.

B

If I pull out code and use only in the in the yaml file to install code, then, if somebody clones code card repo have to figure out what version of code they need to install and how all of these things have to run and our make files have co bill and we do and we won't know what version that will all be documented, but not have automated way of figuring out. That's the problem.

A

Yeah, okay got it, but so so it doesn't interfere with the main scorecard go mode. I guess that was my question. I'm yeah.

B

A

B

But I'm not able to upgrade any of these, because these tools are colliding with each other, so much they're, not straightforward and they're. The similar problems even also ran it too.

A

Yeah, that's my concern. I don't know anything else. Sorry, any additional question for navin.

A

B

Yeah right all right, yeah that'll be better.

A

Okay, I guess no advice for you, okay, um so I don't think we have any other items, um so I guess we can con. We can conclude. Is there anyone with a question before we end? We have another five minutes.

G

uh Do you want to figure out the facilitated facilitator for the next, which, when.

A

You're also volunteering, yes um yeah. So if there's no other question, uh let's decide who wants to be the facilitator for next time? Basically just doing what I did today um so who's interested.

B

It need not be any other scorecard computers, it can be anybody else, so we want to give an opportunity for everybody to be. Somebody wants to.

C

Yeah I can, I can do that next year.

A

Cool, that's great sure, but thank you. Thank you.

A

Okay, so let's add sripad as the next facilitator.

A

And I think we can end uh on this unless there are further questions.

A

So I think we we're done well thanks everyone for attending thanks for the conversation uh and see you all next week or in two weeks, thanks yeah yeah thank.

H

B

um Is the next two weeks the the summit, I'm just trying to think.

A

It could be um two weeks is what 16 or 17. yeah.

G

A

The summit is on 21st or something yeah.

B

21St yeah right, um okay, we should probably plan to have obviously, um except as then the team like. uh I know I think we can't be made able to make it, but we should probably have that in person, but we can still do that on the summit on the 16th yeah. Okay, perfect! Okay, thank you.

H