GitLab Secure Stage, 23 Jun 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Secure Brainstorming - Security Report Schema revision handling - 2020-06-23

Description

Secure stage brainstorming session on handling SchemaVer changes made to our Security Report Schemas

Agenda doc: https://docs.google.com/document/d/179JL5RzbgSIz2XZewbYn79cuX7_vUtte_TcoLwUUC5o/edit#

Security Report Schemas: https://gitlab.com/gitlab-org/security-products/security-report-schemas

A

Hello, everyone: this is our secure brainstorming meeting on Tuesday for some of us June 23rd 2020. Today we were talking about whether or not we need to release new versions of our security report schema when we add required fields and other related items.

A

Okay, so would anyone like to get the quick intro to what we're talking about.

A

You know cool okay, so during our secure weekly, this topic came up and I think that the prior reason that cam raised us is because there's new, emerging quest to add a field called vendor to our security report, schema for all security reports that goes within the scanner object.

A

This will use to capture which the vendor is providing the scanner default. You negate lab well, maybe not technically default, indicate lab, but by usage we are all good lab and it can also do things like white source, so I skimmed through that merger question related issue. I, don't know if someone else has more context around that, but we may need this in the future for showing vendors.

A

Presumably, if it's missing it is get lab and it matches all her former ones which we have not provided before. There may be exceptions to that which I think white source might be one of those because they don't currently provide this yield, since we don't really support it yet and.

A

If we're talking about two different things, you we're talking about adding this as a required field to our schema and whether or not that reflects in our UI as well, okay, so current states, thank you absent cam for adding these points when adding a new optional field. So far, it's been considered an addition, change and quick refresher on schema, ver model revision edition.

A

When you make a breaking change that will not match historical data, that's a major change if it may affect historical data, that's the equivalent of a minor change between the revision and the equivalent of a patch is called an edition, which is when you make a schema change that is compatible with all historical data.

A

So so far we have been making additions with new optional fields.

A

New scan type secret detection has been considered a revision change and no fields have been removed. So that's cool. We don't have to deal with that. Yet I know required, isn't an added? No major releases have been made.

A

So if we add new fields to our schema, should they be marked as required. So.

B

I think one of the confusing parts are part of the discussion around. This was understanding the scope of that versioning. So if we're just talking about the versioning of the schema and the JSON, maybe the the conversation is just around that and then what rails does is a separate conversation right. So whether rails requires a version whether it's backwards compatible, whether it defaults values, things of that sort, I think that might be a separate issue. I think when we're talking about schema version and how we handle that.

B

But that really needs to be its own atomic discussion right like what's the right way to do that from schema, and then the rails is a separate question right, like we can say: okay rails, if you don't have the required field, fill it in with a default whatever, but I think we don't want to conflate those two because it gets really messy. If we do that and it's it's not technically accurate.

C

You're absolutely right, I think that was the part that was not obvious to everyone and yeah. We I don't see the problem with saying that from now on, this field is required in all the reports. It's not tied to, as you said, to the race back end, that the field will always be optional for the race bike in, for example, and that's that's fine. If you don't add value, we don't just don't display anything. That's not.

B

C

B

Just so, if we said it's required and we agree that that's a new schema version bomb, that's fine! That's how we handle it on the schema and then the rails. We get to decide how that handles it. Maybe it can handle back to version 1 or version 2 or whatever we said. Rails has to have a minimum version or whatever, but that's a separate issue. What the.

C

Answer is simple, since we already have a lot of thing, gonna be teased in the database and we don't have that data. It's not required because.

D

We don't have the data so right. So what's the point of making this required in the schema, because.

C

We want that other to be an always present in the future and especially for forest. It's going to be obvious. It's going to be get others at a time, but for the vendors we want to make sure that they are going to report with their control name.

B

C

B

A certain point we can also say any vendor- that's got an integration has to be on version X of the schema all right, because we don't want vendors, just giving us two pieces of data, we're trying to display 30 in the in the dashboard.

C

B

C

We want to add their name in the dashboard, but even what.

C

They can say we were not able to generate yep.

E

That will allow us to to say, for example, starting with 14 dot o. We no longer support any schema prior to version X, and this allows us to move forward and deprecated all the report. Structures and drop the support from the raise application so and Ling historical data would be another challenge.

E

So it looks like we are agreeing on this at least.

B

Yeah, so it sounds like the schema version is just strictly scoped to are we updating the schema version based on what we want to add required or not, and whatever that whatever those changes are.

B

E

Should we go through the question of camera and try to put in and throw there.

A

Like I agree with one a: is there any disagreement with that point.

E

How much sure I understand this one me.

A

Neither so I I think in this case it's just if a field is conceptually required like vendor. As you said earlier, Philippe, we kind of need that then it should be required.

A

I think he's it's just a nice to have, because that's ideally what we want there, it's going to make their lives a lot easier.

A

I think we've essentially already agreed to this that it makes sense to make that required in the schema. Just not the rails, app I.

C

Don't get if it's required, it's yeah nice to have two contradictory ideas in.

A

There I think it's nice to have it be required.

A

B

I think again, I think this is where we're completing it it's required in the schema. If you produce a report, we we need the vendor name, so it has to be in the schema and anyone building a scanner has to provide it on the schema. So when you're writing your analyzer, if you're on version 2- and you want to go to version 2 point whatever this is- you have to have that field on the rails rails is going to treat it as nice to have if it can get it great, it's gonna display it.

B

If it can't wheels is going to deal with that, gracefully.

A

C

Start using shade.

A

Most language for these things, yep.

C

C

Think the nice touch, maybe they're nice to have is, if you want to stick to the current schema version that doesn't matter vendor name. Maybe you can do that, but that's.

B

Yeah and that's the way, if you have an analyzer- and you don't have- let's say the scanner name, you would use a previous version of the schema version. So you'd use a previous version and at some point, get lab is going to say: hey. We no longer support that version in the rails. App. You need to go up to the new version of the schema.

C

That's a great question: do I wonder if we already have some kind of requirements like this, like some fields are absolutely necessary and if you use another version of the schema, it's not going. It's going to break the Basso, for example.

C

Think that I've documented dad's, no.

E

Because we're at the beginning- and this is a first iteration of the schemas- we don't yet have the verification- the validation of the Kinski- know any place. So it's fully theoretical right now and.

C

We mostly added new fields right, we haven't updated fields or removed any any of them, so.

E

We did something, let you a similar image or children, because it's what I was going to say. We already did that something similar in the past, because when we move to the legacy format to this one, we moved from an array at the top level to an object. So this was a breaking change and we moved to version one to version one to version two and we wait to any supported version, one for quite some time until a major version of gitlab, for example. So this is a similar process here. It's just that now.

E

It's officially supported by this schema.

A

So when you have like a field job like CDE, when we drop CVE, that would be I believe that would be a revision because it doesn't really matter if they send it or don't send it. We just won't process it on the rail side. So the.

A

The idea of I guess I'm, it's easy for us to to find rules around the schema to ensure that we get all the data we need. That's I, guess that's the big difference between the revision and the addition. Is that whether or not we care about processing that data so requiring the vendor works for us when we don't use it, but once we start requiring it, that will be the major version bump.

A

So yeah I mean in the UI.

E

That also some distinguished distinction. We need to make a thing between what is.

E

Strictly required from a functionally II perspective, from what kids recoiled from a design perspective like. If you don't provide the vendor well, it will show an empty string somewhere in the UI. It won't break the variety management processing and any of the workflow based on the variety you should don't provide the primary identifier. Things would just break so Daddy.

B

Yeah good yeah, as you see, there's another kind of cheeky way to do this, which is let's say we add the vendor. You add the vendor as a optional field, don't bump the version number, then you bump the version number and require and then it's a required field.

B

Right so it's optional in the existing version, but it's required in the next version.

B

Which rails would handle this the same, the rails side would handle it the same way. But if you went to a later version or to a newer version, its then required that might add more confusion. I don't know yeah so.

A

Do we want to consider, within the scope of this discussion, pinging two minor versions of the schema within the rails app or how we want to handle versioning there or do you're just gonna talk about the schema today, I.

A

Like that could be a big topic um so far we're in agreement. Maybe we just stick with the schema, but I don't know if we can separate the two. Maybe maybe we just can keep going with the questions here and once we get to the bottom of the agenda, we see if that comes back.

B

Yeah I'd say: let's try to get through these questions and then maybe we can figure out how where else needs to behave, cool.

A

A

We do not consider this. A breaking change is that true.

E

I would agree yeah, but it's been serving the breaking chin from the race plus 50 here, unless you knock perspective, I think it's from the race perspective, but yeah.

A

I mean I think adding adding a new field. I can't imagine that being a breaking change and if we don't use it on the rail side, yeah.

E

But brick and cheddar of it. If, if you don't do it, you'll broke something, but here no I mean I.

E

Says for the raise up, it won't be a breaking change, because I work on police itself.

B

B

It depends on what that field is so, for example, vendor name not a big deal right, because we can just not display that value. If you were to add an identifier or something that you have to key off, then not having that field would be a breaking change.

E

Now because in it I mean this is a very very, it would be a very specific use case, but usually you would have such need when adding a new feature. So let's say we're adding a feature in a new minor version of gate lab, and this requires specific data, so it requires a new field to be present. So from this new version of the schema, the property is required and if you want a feature to work in it lab you need to have this version of the schema with the required field.

E

But if you, if you don't provide this information, give like we see work, you would just you just won't. Have this feature so on the right side, we will develop that feature to work only if the data is available yeah and if you can't, then we have to do a breaking change in the minor version of gibla right. Wait for the major one yep.

B

Yeah and I'm fine in this, particularly like we can just keep this to the concrete example we have here, which is if that about. If that value is not there, we've still, who else and still Ryan I'm sure, there's some counter examples, but there's no point in going through all those right now we're trying to come up with them.

E

Okay, so when Aeneid or crayon field is added to the schema, it doesn't happen. The analyzers, when analyzer update the reports to confirm to a more recent version of the format they can add, is that they can't, they must add required fields, since it should validates against the schema. They should because good idea, but.

A

Do we have a issue around validating the schema for languages yeah.

E

It's not clear yet how we'll do it? One option is to have this as well as a key a so that follow it downstream pipelines. When we run it, we prot we validate together Craig's version of the schema, but.

E

It's it's currently inserting up for.

E

E

Humana recommends that you required fields our model change. Well, then, we should follow that look at the schema version. It should be independent from everything else. I think we should comply to this.

E

In subject because I say all so, if you'd agree with that key subjects.

A

There's an anti-pattern, but is there utility in coordinating edition, so we can release versions more, so we can greet group changes rather than every individual change to the schema being or triggering a new novel change me. That's, maybe there's no point in doing that. We can just bump the model as many times as necessary, but I don't know if that would be valuable to consider.

A

Maybe we need an RFC issue within the issue or within the security report. Skiing, a repo or something I.

E

Think it's a bit. You know when we are doing new version of the analyzers like do you release exactly after merging a minute request of the you went from some do above can mean to a new version with multiple changes from its pledge request. Yes,.

A

We we have released candidates, so we can do. However, many of those we want.

E

All right next one, interestingly, it has argument that new optional feeds are a revision change when additional property is true.

E

This one is a bit tricky. I spent some time. Looking at this yeah, it's a it's, not clear anymore in my mind, but yeah this additional property is, is at Siam, I love sitting for the schema. That say, is the report valid if it contains only what is mentioned in the schema or if it contains at least what is in the schema. So if funders, if so value, for example, up crushing more properly that what we declare in the schema with additional prepare is true, it will work, they will click considered valid.

E

But if we say false, then at that week we considered invalid.

E

And this has a fundamental distinction on the way you are doing. Revisions.

A

I'm not sure I follow that. um Can you say that.

E

A

Use different words: it's.

E

Not exactly clear in my mind and the implication, but additional prayer is mean if it's true it means you can already have many additional fields in the report and it's considered valid. So if you add one or any one add one, it doesn't change anything. So it's more like a revision than model change, because there is no. There should be no breaking changes. Otherwise means, if any wonder, provide a report that contains additional fur. That is, and we all know that it could break our app. We don't want this. Do we.

A

Do we allow additional properties underneath fields, curling yeah,.

E

I was again that, because I didn't want somebody to put everything, they wander and I still constrained them into specific field that we had for them. But there was good arguments again that and they I'd the merger question yeah.

B

I mean I. Think part of the main reason is we didn't want data loss, so if you have a scanner, that's generating 50 fields and get lab can only use three of them.

B

If you don't have a place to put those extra 47 fields that result in data loss that just gets thrown out and so having additional properties, you can just throw those in there get lab, blissfully, ignores them or should blissfully ignore them, and we just have those extra fields.

E

What they can do, then, is I mean I CLE. This is still my vision. I, don't think we have settled something that is agreed on the world stage, but the purpose of the report. The secure report is to feed the arrays application and its features, so everything that we don't liberate. We don't need into this report.

E

If you are worried about loading data, historical data coming from scanner that we don't yet leverage, it's still possible to put the raw report as separate artifacts that you couldn't get your use or provide directly to the users, because if certain users want to use them because.

E

If they are available, then she's a report, but we don't pass it on, add story in the database. It will disappear with the garbage collection of the artifact anyway, so I mean not a big deal. We can share that later, but at least is the current situation for additional properties, but I think there are other arguments to keep it this way, but I, don't recall them, I'm, sorry, so anyway, right now it's true. So, okay.

A

So for this one I think that make sense, cool, I understand this time. Anu doing do we need to talk more about F or.

A

So we're giving up on time some might say we're over um is there anything that we need to address remaining here. There's ended a really good job of still in this. How do we need to wait for new version so point to I, don't think so, especially if I'm.

B

A

Them decoupled for now, yeah.

B

I think they should be decoupled and it's really just a limit on how how they get how the the monolith is per coded and I think we want the model it's good in a way that does not require the breaking ginger.

A

Cool, what versions from two of srf are supported? We figure this out agreed. We figure this out and document it and test it. So.

E

Far, it should be old because we just had one major modal version, so it should be all, but it means any additional fill is not fully required. So this is that really true.

E

This is where I mean it's well, it's true, because you put all of them, so the last one when it's required and the last one or in the previous one. It's not based on that.

E

It's it's more about yeah! It's compatible involves versions, yeah.

A

Do we do we support a version, one still top-level.

E

Vulnerabilities right no in 14th at all, we dropped the legacy, data proxy report and continue scanning report, I, think cool, but.

B

The rails that may be able to parsers just.

E

Fine, we drop the author just for continuous, getting and I know we drop the patter, but uh but the the odd do.

B

Sometimes, when your mats- and we don't worry about the old code, so if you have old artifacts, it might still be working. Just fine I think that's the the biggest challenge here is rails. How much rails knows about the schema changes versus how much rails is just smart and says: hey I don't have that field.

B

Let me do this and I think that's something that we need to define very closely as to just rails, who's ever program, that rail side need to go and look at the schema, changes and understand ever change or are we gonna? Have some guidelines like hey? Look for you know anything between these versions and if you don't have the field just fill it in or make it blank and I, don't know if there's a standard answer to that question.

B

A

I think I'd also get in gets into the the pinning to minor version in our CI templates, because a certain point analyzers are still pointing in the latest version and if you're still on 12.9 things are going to get bad. So it's we really have like three separate versions that we're coordinating yeah.

B

Yeah exactly so, if you pin to an old version of the analyzer, the old version of a minor is spitting out an old version. The schema and rails doesn't handle that old version. The schema, everything's gonna work and then it's gonna go to parse it minutes. Gonna, say I, don't understand that schema version, or it meant just there. A lot.

A

E

That's why we initially goes with just one major for everybody, the same major everywhere, and it was what to avoid that kind of stuff. But yeah.

A

So, okay, so yes, we should test it so far. It should be all of them.

A

What happens when they are not compatible?

A

Do we support everything forever or we have a standard, three versions back process, so I think that we can do a similar thing, although somewhere we have to start tracking version, support for rails.

B

Yeah I mean the way I would see. This is potentially that the rails app has a in a loud list of version numbers for the schema version. So rail says if it's version, blah blah blah blah blah blah blah I know how to deal with it and it sends it to its own parser and then I could see rails saying okay, this is a version that is not on my allow list and it needs to convert that into some kind of error message. It goes out to the user and that could.

A

B

Whatever analyzer you ran is not providing me with a report, I can parse. Do we have an issue.

A

For error handling within the parser still because that's kind of been a long-term pain point. We can say something went wrong, but we still don't have a good system for that.

E

There are already some mechanics in the back in code to report their worlds of different parts of the the parsing, the processing, but not fully in to end. So it's not showing up anywhere.

E

A

At least for the time being, you'll see a big banner that says: excuse me that secure report parsing failed or the mr widget will break so there's something.

B

Okay, but that sounds like something we need to give the user some better: better output, yeah.

A

If you're using something like burger crest approvals, then that should be covered because much of us approval is reset approvals on push events, so it will default to unapproved rather than approved. I. Think that's the only case where we're really I think merchandise. Approvals is the only real feature we provide currently for, like active gating.

B

Okay, so I think we may have talked about this in our weekly who's responsible for parsing. Those report, like checking a schema version than parsing that.

B

So if we create an allow list of these schema versions, there needs to be lets, say a migration path from you know, one version to the next, which rails is gonna, let's say, default the value we don't really know who is responsible for programming that and testing it I believe.

A

David said, there's a meeting this week to expose that I.

E

Think it's next to the day or next to day Tuesday, who winds up in Hawaii, it's just 25 minute, I'm, not saying we need more of it. Yeah.

E

Like I'm tangled seeing that say well, if you need to work on it, then you're responsible for the changes you're, making there that's just cool from it. What no I think.

B

Yeah, it's just a problem, it's the scope of testing right. So if we on the gas side, we add a field, if it's not there and then there's there we'll test that, but we have a potential breaking something from any of the other teams, because our window is very limited as opposed to. If our window was the dashboard, we have to make sure that we can read all the reports and deal with those consistently well.

A

B

Think assigning it to individual teams is nice, but I think we're gonna end up. We have the potential breaking things from other teams, because that's not our show.

E

It should not break because, unless we're changing mine on this, they fundamentally follow the same process, the same behavior and the same data model, whatever the repo type. So what.

A

E

Have additional trouble is that I useful for display, mainly today, if we change and add behavior, this behavior should be conditional to the presence of the data, so any even remedy that don't have it, whether because it's an all day it or because it's a different report type that doesn't probably provide that data. The features should just be disabled, but it should not break.

B

Yeah I'm thinking like, for example, if if we add a field dashed at the field, we go update the rails parser. We have all that data in there, and so we may neglect testing. If that feels not there, although I guess technically, we should test if the fields not there for backwards compatibility yeah.

B

So if we tested for backwards compatibility that would ensure that we don't break anything from sassed or CI yeah.

E

Basically, all new features we hiding on top of the brevity's be ends like that, because right now.

B

If we naively just test and say oh yeah, it works this new field. Is there we.

A

Don't have to if.

B

We don't test our own backwards compatibility now, so there's that scenario right, which would just be not necessarily good engineering but like it could happen where we know on. Maybe almost all of our users are in the latest version right. So we test that field works. We forget to test backwards, compatibility, we roll this out immediately. It would break stuff for other teams.

E

The DUI is breaking if everybody's, not there, yes, but I'm. It's a pretty.

B

Well, I mean it might not get to the UI, it might just choke on the parsing. That's that's I think the bigger issue, but.

E

The way the parser are made, you have a current password that should contain all the common behaviors. So if this is something very specific to test I, don't I, don't think I mean I, don't see anything yet that could break the others. If it's just not done for the others, it just don't do anything additional to the user workflow. So it's just a matter of when we leverage that additional information and.

B

E

Far most of them are just for display, but if we start adding features well, then people definitely need to think more about well testing the feature but yeah. It could happen that you're testing just for the death, the remedies and not trying to display it was apples of reality page for another type and they break it can happen. I.

B

Know there was a small failure we had recently I think was a container scanning where just kept reloading. Do you know what the details around that issue were that bug I believe.

A

That was for the the security reports, repo that uses fixtures of old security reports for free, easy testing, and that was there. The scanner object was missing, which was added like in an older version of that probably had like six months ago to the container Scania reports. So is parsing. An old copy of the container scan reports that didn't have a scanner object. I want to archive that repo by the way. But this sure it's.

B

A

For this yeah, it's sort.

B

Of a discussion.

A

B

Yeah, so these are kind of what we're talking about like. If you have an old report, so let's say SAS or dashed or whatever has an old report, an old schema and sassed is you know, whatever six months ahead of us in getting this schema I? Think.

A

That the the primary difference is that we parse off the head pipeline, so there shouldn't be any there shouldn't really be that many occasions where we are parsing. An old report general the generation of a report and the parsing of that report happened almost simultaneously. So.

B

What I'm saying is like someone could pin to an old version of gas that doesn't output the latest JSON, so I could I could pin till it's a version? One of I got version two obsessed.

E

Yeah, this is where you have this competitive-eating metrics between the analyzer and the right application, and this is why we saw for a major number Pinder and that each user override this it's their own risk. That's a big challenge of moving to a minor one. This yeah.

B

And I think that's just where error handling if we make that transparent, so it just as hey, we got a report with the reports, an old version and hopefully, where our version exists, and that report is always gonna be the same so that at the very early should work.

E

But this is outer when transferring to a new major version, because, depending on how much time you have difficut ideale report or you'll, say hey, we are deep rigging these versions, it schema. If we just take three months, it's it's really tricky. We should avoid that. We should keep it deprecated for a very long time because say in in February or March you have the older version of the schema, and now in May we say: hey, we drop, we duplicate it and then you may say we no longer support remove it.

E

We remove the password capability for that all schema, and then you you go to a null project, restart the pipeline or upon another another merge request. The artifact will still be there, so we would try to pass another artifact, and this is when things break.

B

Yeah I'm also curious what happens when people do upgrades from like if they're on I don't know eleven point nine right and then they go to thirteen wine, so they're the calendar time hasn't switched, but then all of a sudden thirteen one is trying to read these old artifacts like very, like very old artifacts yeah.

E

That's an issue with support and well yeah. Just just stay up-to-date well.

A

Yeah, that's it it's a good use case. Well, do do we we don't actually in any place in our documentation, recommend pinning to old versions right just in the troubleshooting for, like the rule, syntax, I think.

B

Certainly not on and I I, don't know why we would encourage people to pin to a particular version, I view pinning to a version. As a great, like you said, a troubleshooting, our support thing like hey: it's not working I just and then they go. Oh yeah. We released a new version of the SAS scanner last week. Why don't you pin to a previous version and they they get it working? So that's. That's the only case that I would I would recommend a customer. Do it.

A

A

At a minimum going back to there, where was this yeah I? Guess just the root for this one 3a. We should figure this out and document it right now. I think it'd be like a one-column compatibility matrix and we will do everything we can to make that not more complex yeah.

B

And it looks like what we need for our test. Suite for rails would be to have versions of all the squared schemas. So if we're supporting version to 2.1 2.2, we should have, as part of our test suite regression analysis against those.

A

Yeah I think I can already say that I think a lot of the fixtures are quite outdated in the rails. App other people might be a penis, but as far as on where they I'm gonna do a little well and.

B

If we have the regression test, so if rails tests against version to 2.1 2.2, it doesn't matter what we do with schema version, because if we say three, four or five, whatever you know bump those two major releases as long as rails knows what the parse and has a test suite. Those versions are, to a large degree, arbitrary to Rails.

A

Yeah make sense.

E

So, just to clarify what Andale means here.

E

Sorry because I was talking you would you jump to the point number four.

A

Yeah sorry I just added the the for a was.

E

Right and what I wanted to say here is it's misleading that we know which two new versions came out? Let's say: hey, you have asked an object that provides these entities information, but the race implementation is not done yet. So people might try to use this new version of the schema, but they won't see any benefit from it. So maybe we should try to synchronize those education.

E

Well, we're always gonna.

B

Have to do it in that? Well, we don't have to, but it's gonna be easier to do it in that direction. Have the schema provide data first and then have rail have rails display it? If we just have already display it and there's no data, that's kind of useless programming.

E

It's easier to do this way because it's just clarifies a specification and it's easier, because if we start implementing a feature and then go back and say this is how the data should be. It's a bit complicated, it's more from the advertisement around this. So if we keep this as other release, candidate I think it's fine, because it's an upcoming feature. It's not yet my register.

E

Again, it's not a big deal, but if some integrators are looking closely at our new version of the schema, they may try to to use them and do and even for us people see that the schema has asked an object. An engineer might find a where is this used in the application? I, don't know about this one right.

B

So in terms of doesn't handle it, we're really talking still graceful failures. We haven't yeah and I. Don't think we need to go through like what would happen if it's a catastrophic break or like really a breaking change, that rails has no way to handle I think we can talk about that when we actually run across that scenario.

A

So I'm putting no here, no, we shouldn't prevents for graceful, fair failures and I mean I. Think that this is just know in general right. We don't. We don't see a use case currently where we should prevent this right.

B

And- and we want to work really hard to prevent this because it's it's gonna- be a big challenge to try to sync all of the analyzers and third parties up to it. So there's almost no way to.

B

Prevent publishing a new version.

B

Yeah so I think Olivia. Your point, five is exactly what we're boiling this down to, which is its required in the schema, but it's optional in the in the rails, app.

A

So yeah, so when can and and to recap, is there a point at which point we can make it required in the rails up I? Guess that's a major version so.

B

That would be right, so at some point rails will say: I no longer support this version of the schema just.

A

According to compatibility matrix, then not really right.

B

Necessarily and then what that point is I would imagine we. We could sync that up with major major releases.

B

We would obviously want to check make sure all our internal analyzers are complying with that, and that might be something that we, when we release a new version of a schema. We say this will be required by such and such date. So if we're really versions of the schema, we could say version 3 of the schema, which has all these required fields must be emitted by your analyzer by whatever this time next year for 440 now. So anyone.

A

B

So anyone who's writing an analyzer. Maybe they wrote it against version 2 of the schema. They know that they have until version 14 to get to the next version of the schema.

A

This might be asking too much. This feels a bit JSON API II, but is there a way within schema, ver to specify relational um like fields with deprecation timelines or versions or or anything like that? Leave for, like a metadata property on schema, verb for field support? I, don't feel like there is anything like that, but.

E

I don't recall and seeing anything that this.

E

We call this out in the in the description of the field weapon.

B

Okay, you know I mean we could add something to our documentation. That says, you know version two will be supported, at least until version 14 or something to that effect. Yeah.

A

That's probably a lot simpler. I was thinking at a per field basis, but that sounds crazy. Complicated yeah.

A

I'm going to embolden this TLDR, which I think covers just about everything, we've talked about required in schema, but optional and rails app. When we can require Lincoln, we require it, be a compatibility matrix but likely stick up in major, give out versions.

B

So so, in other words, at certain and major gitlab versions, we will drop support for oldest chimas.

E

A

This covers six as well, so you know just move it down.

A

um What is 7/8 about is this I think.

B

We I think we covered what 780 does, which is rails, is going to look for the schema versions and then see if it supports it and then, if it supports it, it'll know how to migrate. It.

E

Will have to drop.

A

So how do we want to move forward with this I feel like there's like seven or eight issues? We can create out of this and summarize this somewhere host just do we have a dri for that or do we want one.

E

I was wondering if you wanna go with another CID. If I can time zone I mean I think we we nailed it this morning, but it would be great to have a like some feedback from other engineers, just in case they are objecting with what we said. Oh it's.

A

Something this afternoon then yeah.

B

And I think maybe maybe the way to wrap this up is to summarize this discussion in our documentation on this schema repo. So we can just say versioning and then explain very clearly and then, if we do that as an MRI, we can make sure that everyone's on board and that we've documented it well.

A

Are you volunteering stuff I like I, can try summarizing this yeah yeah.

B

I mean if you can I, don't really have the bandwidth right now. Cool.

A

I will do that then, after the apec call I'll put on the secure calendar after this meeting sounds good.

B

All right, thank you. Everyone, like thanks.