 Hello everyone. Good morning. Good afternoon. Welcome to the 7 September Hyperlegio TOC meeting. Quick note before we get started. So the TOC charity Tracy will take some time today to join. So I'll kickstart the meeting and we will let Tracy join in and then I'll hand over to her once she joins in. So before we get started with the meeting, I see all the participants on the call. We are all familiar with the antitrust policy. So we are all people joining in from different companies. We are all expected to behave well in the community. I hope we are all familiar with the other relevant classes within the antitrust policy itself. I'll move on. All are welcome in the community. So if you have something to say, please raise your hand and we will let you speak up. And moving on to the agenda items, the announcements for today. There will be Dev Weekly newsletter that gets sent to a large number of developer community who's come to Hyperlegio website and they subscribe to Hyperlegio's newsletter. And this is really a good forum for sharing information across on what's happening within the Hyperlegio community because this reaches to a very large number of community members. So if you are a project maintainer or if you are planning to organize an event or if you have something related to project that you want to talk about or anything in general, even if you have a blog article or a feature that you want to discuss about. All that is needed is go to this link and add a comment saying that this is the information that I want everyone to know about. And that's it. That's how it would be. I'll cover this next item. Sure. This is basically a website update. The governing board approved this policy on April 2, 2019. And this is just a complete iteration of the approved licenses. And when you can and cannot use licenses, specific licenses. This has recently become in another context. Let's come up in another context that this wasn't very well documented. There's another project that wants to use a license and Tracy point this out that this was an oversight on our part. So that's all this is saying this is not a change. It's just been added to the website. So to you or unless anyone has a question. Um, we're good. So, so I think we discussed about this briefly in one of our previous to call as well. Um, so eventually we will get this and party was a discussions. So, um, one of the thing that we could look into is about allowed licenses that I was talking about, we can put up a policy through the to see. Okay. Yep. Thanks for bringing that up. So was there a question there? Oh, no, I was about to cover the context for why this was being discussed. Okay, moving on to the agenda, the continuing the agenda items. We have two quarterly reports that are up for review. Sella was raised about a week ago and. Sorry, so long was raised about a week ago and shallow is raised. It's in rough state. I don't see any comments as such for the so long report. And I don't see any reviews happening on the seller report. And if you have any questions that needs to be discussed from the report, please bring them up. Okay. And related to the quarterly report itself. I don't see anybody raising a concern on that. So, some message from Nico that hyper ledger fire flies report is due. And that will be. The project team is requesting for extension to sign their report for this quarter. Any comments from anybody. Or any thoughts. This is with respect to firefly quarterly report. And Nico's question. If he can delay a week. We would need to vote on that. Right. I'm so I know previously very recently, even hyper ledger sort of was asking for extension. We, I mean, we could generally ask the TLC member and we can assume that TLC is okay with it. Unless somebody raises any questions and concerns. Again, one more call. Like, if you have any concerns or comments for the hyper ledger firefly, please raise it now. Otherwise, we will assume we can proceed with assumption that we are okay to extend, give them an extension by one week. If you want anybody to verbalize their agreement I do. And then a week is really not much to say so. That's reassuring. So. Okay, so we will assume. I mean, we, so based on this discussion, we, we will now proceed assuming that firefly team has been granted on mobile to send a report in. So, moving on, I know hyper ledger transact report was due. And I did reach out to the project team and asked them for the extension. If they want to the project itself to stay to remain in the dormant state. The other option is the transact project go into end of life and as per our governance documents that still allows them to a period of about six months to remain for maintenance. I haven't heard back on that particular comment itself. However, the project team has replied to the previous question that they would like to remain in dormant for six more months. Any concerns or comments on that topic. I think it's fine to live in dormant for now. Excellent. Doesn't really hurt anything. Peter. If they don't already have. The some sort of dormancy notification on the read me then I would recommend that they put it on. That's that's the only thing I'm just I would just be very that. If it's dormant and they're applying. We're asking to be dormant. Again, as in continually. Then I would be very that people. See the project page and then assume that it's not dormant. If there's not a very clear, very bold letter notification on the top of the read me that says so. Thanks Peter. So I can confirm that the transact repository has a reading. And that is a warning text, which says the transact project is in dormant state. References that you will see. Issue from there. In addition to that, it also says that any new development within terms like now happens within the sort of library. Yeah, that works for me. No other comment or concern. Thanks Peter. Any other concerns. If not, thank you everyone. Thank you. Thank you. Thank you. Thank you. Welcome to the discussion items for today. We have discussed as the update on our security process. The policy document that we wanted to put up as part of our governance. So just before the start of this meeting, I was also trying to discuss if we should. How we should proceed with this particular topic. What I had was that we have been discussing about the security process policy and. The recent discussions that have happened on the TLC meeting, all suggest that everybody have agreed to the policy statement itself and the process that we should adopt. However, what is pending is. How that policy should be presented out to maintainers and in our governance documents. So. I understand. Stephen is occupied, but he has agreed to put forward a PR for it. And he has also tried it out on how the document would look like within the airy suppository. I was thinking that if we should vote on the policy. Or should we still wait for the, the, the exact text to be put down before we pick it up for voting. Any thoughts or comments from the TLC member? Yes, Peter. I know it's probably a little paranoid, but as for me, I would recommend that we only vote on it once everyone has put in their changes that they want. So that the document is finalized so that there is a 0% chance of it happening that a specific sentence sort of word gets added in the last. That someone really disagrees with and then they just don't agree with it because of that. I know the risk of this is very low, but I would prefer it to be zero because it just keeps life simpler. Thanks Peter. I would also agree. I think we've already kind of verbally agreed on it. So I think we might as well just wait for the final PR, and we can just vote in the PR itself, or by approving it. Thank you. I see thumbs up from Peter. So I would assume we'll wait for the PR. So then we'll switch over to the next agenda item, which is a task for discussion. So this would be the first meeting within the Security Artifact Signing Task Force. The goal for this is to discuss about what should be the process that we follow across all Hyperledger projects and how do we protect the releases that we produce or of the releases that we generate through the Hyperledger Foundation and other repositories. So the topic is wider and I'm, I'm starting the task force like as a few comments that I can get started with are a few pointers that I can share through my screen share, and we can then possibly take it from there. If everyone is okay with that. Let me open my terminal. I just want to have, so I had the option to go through the six doors, which is offered through OpenSSF. So it's a collection of tools and utilities that OpenSSF has that we can adopt within Hyperledger ecosystem. I'm just trying to pull up my notes that way we can start. I can share that and start discussing the topic. Just give me a moment. So I hope you can all see my screen. So I'll briefly cover these aspects. I know I'm not and few of the TOSA members on the call are familiar with and have much more information than maybe what I do. But I'll try to give more information on what we are going to discuss as part of the Task Force. So the problem statement that we are trying to address is to to sign the releases, the artifacts that we produce from within Hyperledger Foundation repositories. It is required so that if I'm a consumer of the project or a specific artifact that is produced through the Hyperledger Foundation, then I have a means for me to verify that what I am consuming is the valid artifact that was produced through this process, right? Otherwise, there is risk that because the code is open source that somebody can clone and add some vulnerable code or any malicious activity can be performed and a binary can be produced that has potential of raising risks. So that's like a very 30,000 feet view of the kind of problem statement that we would try to address through this process. So digging further, specifically talking about six store in particular that if we plan to adopt as part of the project available from within OpenSSF, the project itself or like the ecosystem comes with a set of tools than just one single tool, right? So the main objective for us is to have a mechanism or a process where we can sign the artifact and establish a process for people to verify that the signed artifact is indeed what was produced. Now, how do we prove these things? And it is possible for us to have our own infrastructure set up and then do it as part of any releases that a particular organization would do, a software vendor would do, but is that needed for an open source project or like would there be any other options for us to follow? That's where this exploration goes on, right? So the OpenSSF six store has these components, one of that component is called full show. I hope I'm pronouncing it right. So this is a CA infrastructure that is available or probably you can equal, it's an equivalent to a CA infrastructure. The objective of this particular component is to let users of this project go there, authenticate themselves, tell who they are and let the full show generate a temporary certificate that is valid for a shorter period of time. And the key associated with that particular certificate can then be used to perform the signing operation. Now, what's the advantage of this? It's advantages are in terms of the short-lived certificate that we just discussed, right? And also the infrastructure itself provides a mechanism where we do not have to share or store the private key anywhere publicly. So typically if we were to do signing operation without such an infrastructure, we would go and place our secrets somewhere within, let's say, Github Secrets, store it there, pull it during the Github Action phase, and perform the signing operation and that leaves us with challenges of how do we manage the key, who owns it and the whole problem statement associated with that threat. So that's the advantage that full show brings in. Now, the other component that OpenSSF has within 6.0 is a component called cosine. Now, the cosine is, you can consider that to be a client. They do have a CLI and they do have SDKs that we can utilize depending on our need and where we want to utilize it. So the cosine has options for us to perform the required verification or the signing operations, right? And it does provide us commands to do so on a binary block or it could be on a container image itself that we produce. The commands are different, but the concept would remain similar. So that's the gist of what the cosine component is. The other component that the 6.0 has is record. Now, what is this and why is it important? It's immutable and transparent, up and only ledger and not necessarily a blockchain. I know we are all familiar with the blockchain technology. So this is a public ledger or publicly available information and what it records is, every time we perform a signing operation, the produced signed information gets recorded on the record and it allows for somebody who wants to verify to go and fetch the relevant information for their verification purposes. So there are some questions that I could not get answered to I'll bring those up in the later section and we can discuss if others have more information about that. The other component that we will be utilizing is or rather an optional component that is available. And that will help people who adopt hyper ledger binaries or container images in their development or production environment is this policy controller, right? So it's a controller that's available through the 6.0 and this allows for somebody who is downloading container images which are produced within hyper ledger foundation to go and verify if these images were produced as expected, right? From the expected through the by following the expected process from within the open source means that we have done. Now, it's always important that we not just sign but also establish a mechanism for verification as well. Signing short, we can ask developers and the maintainers to adopt a process. However, it is not effective unless the people who are using those artifacts have a means for verifying that or at least they are aware of what they should be doing in order to verify these signatures. So that's where this comes in handy. And some of our projects within hyper ledger foundation, we can recommend those projects, especially which deals with the deployment related things and the projects which do have a chance to see if they can adopt this component into their projects. That's the, I would still treat that as an optional component, but it is important that we document that component. So that's the gist of what is available through the 6.0. In terms of advantages, I guess we discussed that we are not going to store any sensitive information and there's no potential risk of leaking it. And we can shorten the duration of those generated artifact, the key, the validity of the certificate we can shorten that on demand. And in terms of authentication. No, no, in terms of adopting this within hyper ledger build processes or it or maybe get actions that we have. What all thanks to we have, it is possible for us to utilize the GitHub based authentication. And the full show provides that why DC connection which can utilize github's authentication. It does have other authentication means as well. And the. So, so I see a risk in terms of how we handle that identity. With the authentication, I was trying to automate when I was doing the hands on and understanding the 6.0. I see a risk there or when I say risk, it is with respect to should the project teams be allowed to manage this or should it be through the community architects within the hyper ledger foundation right. So, that's one risk that I saw. Now, continuing the other things that that may be of importance for us to discuss here is with respect to verification right. And I know I said record is a public record, which captures all the information that we can later audit. Now, just this thinking through what information would somebody need in order for them to verify the, the, the information which is present on record or like verify their artifact against the information presenting records. So, this has this led me this particular question led me to two parts. One was with respect to container image itself. The other part was with respect to like blob artifacts that we produce. With respect to container image itself. I found that during my experiment that the the signed manifest that we produce, it also captures information relevant for verification along with the container image right and it is possible for us to establish a means for verifying that. However, when it comes to like any other artifacts or blob that we produce. If we perform signature using cosine. I did not find effective means for us to store that information. Right, we need to look for storing that information and this information includes the long log index that that we need for verification and the signature text that we need for verification, the ephemeral certificate, the information that was used during the sign operation. So open SSF six store does define a way to capture all of this or bundle all of this into common structure that we can store somewhere, but I did not find effective means I may be again wrong like if others are familiar please to share that information. I did not find a mechanism to store this information for blob artifacts. And the other thing that I observed was the attestation that we do the common structure that I was talking about that captures all of this can be at maximum have a size of 100 kb. So the summary of all the exploration that I was able to perform prior to this meeting. I can show these commands through a terminal but before that I'll probably pause and open up for comments. And or any thoughts or questions. Hey, I'm sorry, I need to read. Sorry, I'm sharing the screen so it's difficult for me to see what's happening. I assume Peter you raised your hand first. Hello. Yeah, I can hear you and I think just no one else has spoken up yet. Okay. Hey Peter. Peter you're on mute if you're talking to the floor with yours. Maybe connection issues Peter we can't hear you. Yeah. Jim, since your hands up, let's let your sort out is audio. Yeah, it's pretty noisy in your audio is pretty choppy. So Peter will come back. We'll go with Jim and we'll come back to you in a while. Sorry about that. Yeah. Thanks Aaron. I'm not familiar with this suite of of tools here. I guess my first question is that short lived certificate for code signing. Is it a prevalent practice for for using short lived certificates, I would imagine during verification this will be a problem if your codes, you know, the signature on your on your signed package is against a expired certificate. So the short lived certificate concept. That's the uniqueness that we gain when we follow the six store project. Now the information me. I mean the verification purposes right so we would need that short lived certificate and we would need to know that that was the corresponding certificate that the signing key was associated with at the verification time. And I understand like it gets expired because it's a short lived. So the public record that we have in through the record. That's the proof that we have to verify that this was a short lived certificate that existed back when it was produced and it was signed. So there is one publicly hosted instance of record there is also a possibility for somebody to host this outside of that public instance. So these are available both for deployment and and running instance of record. So just to validate my understanding, if a customer needs to validate a signed binary or a Docker image. They first need to look at the certificate to verify the signature, and then they have to query the ledger to make sure it's properly registered there. This is the two step thing right and they have to, they have to build a custom code in their pipeline. I assume most of them just look at the signature against the certificate on the binary itself but now they have to to make specific enhancements in their pipeline to make queries to this ledger. So, I mean that's right. These tools that I spoke about like the cosine tool does have the capabilities for verification built into it. So if I am the controller that I spoke about policy controller that is available that also has an option for verification in built within it. So the in terms of adoption that would be utilizing these tools that we need to look into into our pipelines. Okay, I'm trying to pull up the, sorry, go on. Yeah, I guess the last question, hopefully a quick one is a six door a sort of a standard or popular toolkit. How is it adopted currently. I'm not aware of the adoption aspect. But it is getting popular as I speak defense is hard. You're the right person. Yeah, I was going to say, Jim it's popular and becoming more popular like the CNCF uses six door for instance, several other large Linux foundation projects use six door. The perfect signing is rapidly becoming a security requirement and six store seems to be the choice for open source projects. Thanks, heart that helps. Sorry, I couldn't find my button. This is six door is becoming more widely adopted within LF. I mean that's the plan record for LF. So it's not a mandate, but more and more LF projects are depending on it. Anyway, Marcus, I see your hands up. Yeah, thank you. So one question I mean, as you say, right that I mean hyperlateral is using six door, but are those Linux foundation projects then using this public instance of six door or in particular we call as a back end and I believe this instance is provided by Google at the moment. And I mean, I find the six door project pretty sexy. I must admit, despite the fact that yet it applies ledger technology which is not distributed in terms of trust. So, yeah, right. I just wanted to say that it is hosted publicly and it is through the sponsorship of different companies may not be of a single company. Right. Do you want to add to that? No, that's fine. It's if you go, if you go to six door dev. There's a lot more information there. And would it make sense that the Linux foundation also runs a week or service them. I'm just guessing here. I can't answer that off the top of my head. I will have to dig into it to find out what stores. The LF is pushing towards so I can't answer your question. Okay. Maybe hot or I know I have more insights. I don't know. Well, I would say it makes sense, but that doesn't necessarily mean it will happen. Okay, so Marcus, maybe we'll take that as an open question that we can check back and come back in the later calls. Thanks for that. Peter, I see you next. Can you hear me now? Better. So I'm looking into this. I thought you get Peter. Because I wanted to self host or not. Oh, no. Can you hear me now? Is it better? Hello. We could, but you broke when you were talking about something that you wanted to say. Yes. Since I was researching it last night, and I found that there's five people on their list who have root signing keys. It's like a committee of key holders. And I don't know any of them personally. So I want to just ask anyone actually knows any of these people. Here's the link. I'll put it on the discord. Because if we can trust, if we, if anyone here knows any of those people personally, then I wouldn't mind trusting them. Otherwise, maybe it makes sense to self host our own. That was my initial take based on the last night's research. Can you still hear me? We could. And we understood your question. Thanks for that. We will wait for your link. I remember there was a link in the sixth store. I put it on discord. Perfect. Thank you. And I tried to share the screen, but it won't let me. Oh, sure. Go on. Peter, where did you put this in discord? The number. 2020 meeting. TLC. We still don't see that Peter maybe it's the connectivity issue. Yeah, and if you can, you can try to share your screen. Can you see the screen? We do. Okay. So these are the folders for public instance from what I could gather. And ideally, for instance that we use, I prefer to know at least one of the people on the list personally. Because otherwise, for all I know these people could be completely fictional. So I can tell you, I know, I know personally the first three people on that list. They are not fictional. People. Awesome. Okay, that's good enough for me. So then based on that, I think we could use the public instance that's available. So one thing I wanted to add is, I mean, Oh, there has been discussions because six stores part of open SSF and there's been discussions about whether open SSF should take over the running of the instance that has been maintaining. I think Marcus is right. It's funded by Google today. I don't know if it will happen or not. There's, there's, there's no active discussion on that point that I know off, but it has been brought up before. The other thing I wanted to say is, you know, the way to think of six store this is kind of their one liner is the motivation for six store in the first place was in a way that's similar to let's encrypt, which is similar to anybody to, to, to, to have keys so that they could use HTTPS and make HTTPS prevalent. They said we wanted to make a system that allowed signing artifacts in a similar way, cheaply, I mean freely reading and simply. So that's kind of where they come from. I assume that's what you also wanted to call out. Hi Dave. Hi, so I just didn't understand who was actually doing the signing which identity is it is it the identity of hyper ledger or a specific project or a specific maintainer on a project. Do we know that yet. I can show, I can share my screen again. Good. Well the answer is anybody can do it right so you can you can I mean the release manager could do it. That would be the obvious person to do it when you you're producing new images in our case you either have to know images, and you, you publish them to the registry. You can sign them. And, and the metadata associated with the container image on the registry, they can be the envelope information so that they can find the pointer to the record in the, in the record instance to verify the certificate and signature. So, Arnaud, whoever signs up on the website to create an account can get issued a certificate. Yeah, anybody can do there's no KYC. Open ID. No, there isn't, but with open ID connect I mean you they rely on the way the email address really right. Okay, and so with a registered name be like my own name or would it be hyper ledger. I captured the gist right so this is something that we should discuss within to see on how we should adopt if we plan to adopt this. I'm sharing a screen to to visualize how that would look like for instance right. So as I'm not said as long as anybody have a means to authenticate themselves with the full show through IDC. They can sign any artifact that they produce. And we all we need to do is probably just import this cosine into our pipeline and add the sign command instead of you know I'm showing the verify here but that would be like sign command and then use this identity and I authenticate with this full show. I've signed it right so now the record has a log entry for somebody who wants to verify. They would need to supply the identity which they trust. And the signature that they're planning to verify with the OIDC. It ensures that they want to verify this identity against. So, if we were to adopt in order to answer that question of who owns that identity and then should it be maintainer of a project or the hyper ledger foundation. We could discuss that if we need to put policy around it. It is possible for us to have for instance right like hyper ledger wide identity that we use for all the artifacts. And let the staff maintain it. I don't know I'm just calling out random things here but if that's an if that's a responsibility that the staff can pick it up and they maintain the identity and they can provide that means for different teams in their pipelines to perform the signing and then through hyper ledger we can say if hey if you want to verify any artifact that is produced outside of our repositories. Here is a means for you to verify. Sorry. Put that answer your question. So, the gist is like we need to come up with a policy if we want to. We can use the hyper ledger bot account that exists to do these signatures. Or some similar sort of account that would basically be a hyper ledger. GitHub organization wide. Key that we we store and then the GitHub actions could use that. Yes. Hyper ledger bot already owns a bunch of the publication stuff. So, the answer is, I mean, could it be done. Yes, do I think it should be done. Probably. I don't think there's any more since that account is already publishing a bunch of our artifacts. I don't think there's any additional risk from having those artifacts signed by that account, but everyone on the call is free to disagree. Thanks, right. Thanks. Peter. I agree that it would be. Wait, can you hear me. Okay, sorry. I agree that it would be much more convenient. If it was a staff maintained key and identity and the but did it all. But at the same time, I will say that maybe that's a good first step, but we could also after that step by step work on the solution where individual maintainers can or has to have to also sign so that if there is a malicious binary out there for whatever reason, probably a key compromise, then we can tell whose identity was stolen and compromised and used to do a malicious sign. But that's just that's that's the least convenient way of doing it. And so I agree that just to take one step at a time we could probably just get going with the common staff maintained keys and ideas. So I have not looked into this at all. But I imagine it would be fairly trivial to have much like we have per repo secrets. I imagine it would be fairly easy to have per repo or per project keys. So if one of them was compromised, it wouldn't compromise the entire stack. I don't know the answer to that. So I'm just going to imagine that that's true. And I promise you all look into it. I'm going to go with hard first. Yeah, that should definitely be possible and we would want to do per project keys anyway right. I think so per project or perhaps even per repo. Yeah, even per sub project I mean we we could let the pro my my thought on this was that we let the projects decide how exactly they want to structure their own. And obviously like areas is going to work a little differently than fabric. Thanks heart. Yeah, Tracy. But we do need some sort of consistency for people who are using hyperledger packages to be able to verify them. Correct. I had come in Sunday but I'll go with markers. I'm wondering, I mean, why can't we just I mean, do this as the hyperledger foundation to host by ourselves. I mean, we could, for instance, have a repository where we basically publish the public public signing keys for each individual project and then mean just sign our artifacts and basically tell the people hey, in order to validate this artifact go to this official hyperledger repository on GitHub and use the information to validate the artifact you don't just download it. So, in broad strokes, I agree. One difficulty there. One difficulty there is. I would say ownership. I mean, GitHub, people in GitHub that have the owner role is a fluid set of people. Because all LF it staff can self assign themselves can assign themselves ownership of any repo. We could have another. We can talk through that. But the list of people who have the ability to do stuff to repos owned by hyperledger is unknown. And all we can do if something happens is look at the audit log and see who did it. So I, you know, that's the only downside that I can think of Marcus. I'm not sure if this is a better idea. I mean, a better approach in contrast to six though but I'm just trying to put this on a table and discuss if this is, let's say, a good homegrown alternative. And the point you raised that maybe, I mean, hyperledger stuff would be able to manipulate the data or the GitHub history of that repository. Well, I mean, if there's a way to audit this, that's fine. I mean, the same thing you do then this week or anywhere, right. Well, I'm talking on the org level, not the repo level. So let me share my screen here quickly. So right now, here is the audit log. So this is something that less, I think you would have to delete the org to clean or edit the audit log. So this is the organization audit log. When it comes to who can do what to a repo. That's the, you know, that's the part that I was on about. If we look at So this is the current list of people that are org owners. So, you know, it's, this is a fluid list. You know, when it comes to the audit log, this is less fluid. This is something that GitHub controls. But I guess the same issue we would have if hyper ledger would run their own six store instance right someone some hyper ledger stuff will get access to this instance and control it through somewhere. I don't know, I guess. So I guess that the question there is, do we, the hyper ledger maintainer project maintainers trust the immutability of the public six store that's being run, you know, by the other team. Do we trust that more or less than the immutability of our own six store. Right. Thanks, Marcus. So I wanted to say a couple of things. First, I mean, following up to Marcus, you know, point about where we could just sign publish public keys. Yes, we could. I mean, this is the way we used to do that 20 years ago. I remember what we are publishing releases of some apache software was working on. And it was just like, yeah, you put the top file on the on your on your server with the signature attached to it and that's it. I mean, one of the motivations of store was that is the observation that this is often done poorly. It forces people to deal with public keys and certificates that they typically don't do very well long term. And one of the advantages of six store is that with this mechanism of the transparency log, a record, you know, you only need short live certificates that is produced by social on demand. And so you don't have to keep the certificate around for a long time, and it reduces the exposure and the problems with people losing keys and whatnot. And so they just record, you know, they record an entry in the in the transparency log and you go back to this and that's your proof point. But yes, you could do it differently. There's no doubt. You know, the cosine, if you if you, you know, I encourage you to play around a little bit with it. I haven't done that in over a year now, but my experience has been that, you know, it's well designed in terms of making it super easy to use so that the basic operations of publishing, signing things is very easy. So that's the advantage. It, they really looked at the pain points of the traditional way of publishing, you know, signed artifacts and say how high can we modernize this to make it super easy and mobile. Thank you. But I guess we could also think about a hybrid model right I mean we could still use cosine for other stuff. But I mean, but instead of using their lecture technology, I mean we just use something which we already own. Like a GitHub repository. Yeah, we could. I have to say I'm a bit surprised by the general worry there that I'm sensing about we cannot trust this system. Maybe we're I mean today we're not doing any of this. And, and all of all of a sudden we're saying oh wait, we're going to rely on something that's maintained by some other party we don't really know. I don't know if we can do that. It might be extreme. I don't know. No, I agree. I mean, I think we should definitely do this instead of doing nothing. That's that's true. I mean, if down the line we feel like okay, this is not a trustable system we need to adopt our own instance, you know, so big but I think for now we shouldn't burden ourselves with that honestly. No. Mark was the same. I have comments but I see it's already 10 one. It's so we are. We are at the summit of this meeting. Unless if anybody has any other questions, we will continue these discussions in our upcoming task force meetings. Great. Thank you, everyone.