 Hello. Hello, I'm Andrew. How are you? Good. Thank you. Hey guys. I started a conversation about trying to move the time of this meeting. Monday. I was remembering that it kind of stalled the. I take full responsibility for the. Missing previous meeting. Unfortunately at that time I was traveling so. Good enough. Made it on time. So. Might have appeared as. So I, I think. What. I'd like to propose let's meet today and then moving forward. Let's change this meeting to. Let's see. Monday at. 10 a.m. Eastern time. Next week, but I don't know if it's going to be available for long term. It's about. 11 Eastern. So you said 11. Yeah. 11 a.m. Eastern time on Mondays. Or every other Monday. Yeah. So same time as now. That works. I will reach out. I'll reach out to hyper ledger folks and formally make that change. So in two weeks, the meeting will be scheduled at that time. I actually whatever it will be. Sure. Yeah. And then of course I will be traveling and unable to. Attend. Anytime during that week. I'm not that the meeting can't be held without me. I hope that it is, but just letting folks know I won't be there until the 10th of April. But I'll reach out to hyper ledger and get the calendar changed. Excellent. Hopefully that means Mike lotter will be able to join us as well. Because I think having him on the call. Will be beneficial. It's, it's good to be able to talk to Mike. Actually considering that we did have some. Interesting new developments. To us. Yeah, and when he's engaged, he really is. In my opinion, he is, he is quite capable as a. It's an engineer. So it would be, I think it would be good for us to have him involved. I appreciate it very much. Thank you. Thank you very much. Thank you. Interactions on GitHub. Brief as they were. Brief. They were. So. Speaking of them. I'm happy to say that. The pull request, which bombs trivial dependencies. Or. Can be amended. To accept. A nonvent version of Dalek. What's the name of the. The. The paragraph he was merged. Oh, excellent. This also means that the pull request, which was. Approved. By right, but not by Mike. It can be amended to include other non-trio dependencies. And we can use that as a starting off point. As. I'd like to have a look at problems with WebAssembly. One of our engineers said that there are some issues with compiling Ursa in WebAssembly. And I think that I might know what's causing that. I'll have to do some research, unfortunately, but that will be my next step. In other words, I plan to have a look at 226, because while there are some tests in Ursa, they're not connected to any sort of pipeline. And I'd really like to be able to see the code covers changes in the pull request summaries. I've done that for Iroha. I'll probably just need a couple of hours to get that done, and maybe someone with some experience of GitHub Actions to review. I've added the roadmap in 223, as was requested. We had a discussion with Mike about the reorganization. Should we go through that now, or is it enough to keep it offline? I think the gist I've gotten is that there's general agreement on this as a roadmap. And failing anybody coming forward with really good reasons that it shouldn't be, I think we just continue moving forward with it. Okay. I've also added a GitHub project for this. So there's a primitive Kanban board. I don't know if anyone uses it. I only use it whenever there's a change to the status. And unfortunately, I didn't manage to do much else. The project that nearly got me to quit is very close to getting me to actually quit. So it's been a busy week, unfortunately. I can relate. Oh, did it work out? Please. Sorry? Ah, never mind. Just a silly joke. I like silly jokes. All right, so two, two, let's see. I don't know if I've clicked on the wrong button. So two, two, five, you said it's great. Have you made the change yet? Winking to Dalek? Yes, so as I said with two, two, five, I still have to make it today. Okay. Vendor, I don't, I no longer need to vendor it. It should be usable as is. Okay. As soon as you make, I'll try to pay attention as soon as you make that change. That was the only thing keeping me from clicking approve. That was that outstanding question. So I will keep an eye on it today and we should be able to get that in today. Good. One more question. What do you guys think about a request template? Most of them are at Hock. I want to have some sections which are just posing open questions. What does this do? I like templates in theory. I like the idea of templates. Usually what I, and maybe this is something that we could overcome, but usually what I've seen happen is that what ends up being the pull request is all of the template text, none of it removed or changed, and then a couple of lines about that they're just doing what is being done now. And I mean, we could be hard-nosed about it and say you didn't follow the template before. But I'm open to it. I'm not going to stand in the way of it happening. I'm just jaded, I guess. Okay, in that case, what I'll do is, I'll set a template which looks fine standalone, maybe with some optional stuff. But yeah, it's not going to be as sophisticated as 225. Right, any other recommendations about the CI? Because Ursa is used in many platforms, there's a good chance that some of the things which use low-level instructions can compile in one architecture, but not in the other one, or fail on different architectures. I heard that Rai had an AR-64 macOS and AR-64 Linux runner on an M1 machine for Aries, which was usable for other projects. I'd like to add that to that pipeline, maybe adding a WebAssembly test so that we know when that's broken. We can bisect and find what changes can fix that. In general, I want to improve the test coverage, but I want to do it without investing a lot of time directly, and in terms of coverage, also feature compatibility. There are a few tools called Cargo All Features and another one which was, I think it was called Hackery, which checks for different combinations of all features and says, oh, if you use this feature in combination with that feature, what was the compiler error? Any objections to those things? Not for me. Okay, in our case, I'll get to 25 Marjable, and yes, that's it. I think that we can actually, we can probably close a couple of issues too now that we have a new issue for the roadmap. I suppose closing 151. Okay, it is marked as potentially relevant. Should we just close it in favor of the actual roadmap, which is... 223, right? 223, yes. Yeah. Excellent. Yep. That is done. We have another issue marked possibly irrelevant but it was e-mix. Oh, it was e-mix. This one is not as cut and dry for me right now. I haven't been in Ursa land in a little while. I keep it open. Yeah, I agree. So we're sure that that's fixed. We have quite a number of, sorry, I'm jumping away from possibly relevant. We should keep on that. 185. Well, proof question. Yes. It's a documentation issue. Okay. So should we change the label from possibly relevant to documentation? I think we should keep it as possibly relevant because as far as I can understand, the reason why there's a problem is because the organization doesn't hint, it doesn't put the user in the correct mindset to read the docs because there aren't any and it's a re-exported structure but it doesn't have the documentation of the original thing. I think if we actually go through with 223, that might be invalidated. I have a comment about it actually might be useful. Yep. 193 cannot compile 0.3.7 in portable mode. Yeah. It's another one that as the roadmap gets implemented this should become irrelevant. Yes. 95. 195, re-export AAD. Hopefully when the non-trivial dependencies have been upgraded that would also not be a problem. AAD has changed the API quite considerably and many things which used to be easy to do are no longer actually even possible. So they used to have a generic constructor for all of the AAD types. Now there aren't any. And so the solution is either to implement all of them manually and to copy the code that was just removed or which is the preferred solution to just not rely on it at all. And to tell people, okay, you have to patch these things into AAD and when you get something out, it's the AAD type rather than the ASA type. Sorry if I'm getting into too many details. No, that's fine. I think ending up with a solution that reduces the amount of, or the number of hoops that folks using ERSA need to jump through to get it to work is the best path forward. I fully agree. Replace failure with this error anyhow. Maybe relevant, article 223 again. That is all the possibly irrelevance. Yep. We have quite a number of bug and security labeled issues which I'm not sure, I guess, I'm not sure how, I'm not sure if it was the roadmap, how many of them are addressed by roadmap implementation versus how many need just somebody sitting down and deliberately fixing. Okay, in that case, I'll give you a case study 209. Also, we'll ED25519 Dalek issue. Yes, that's fine. I tried to address this directly in the Dalek recall and the PR sort of kind of addresses it, but it doesn't actually give me enough information to say that we've definitely fixed it because the issue isn't phrased as if, here's how you reproduce it. It's phrased as unsafe libs, the library that is used for signing ED25519 Dalek possibly contains a security bug, possibly contains. Doesn't really tell you much how to reproduce it or how to verify that it's no longer there. And given that it has the security label, I'm not sure that anyone other than a security expert can really definitely say that we would rest the security issue. And what I can understand, just upgrading Dalek is enough to say that we are safer. Safer doesn't actually mean that this is completely invalidated, but as far as I know, this is not a CDE. This is just a potential stack on the flow bug. And also the README mentions that it is not likely using the, that URSA using the unsafe library will also be unsafe which come to think of it, we could just add unsafe decorations around the functions just to be safe, no pun intended. But this changes the API for no reason other than communicating to the users that might be at an angle by which this could be under some circumstances incorrect. The Rust guidelines are very clear that this is not how you use unsafe. Unsafe is used specifically in other cases where you are violating the borrow checker guarantees. And in that regard, we could just close this one. I didn't add the label possibly irrelevant because I'm not qualified to say whether or not it's closed or not. So yeah, it's a bit of a tangled mess. Is this, I'm assuming not, but is this at all related to the recent Dalek 25519 conversation about scalar arithmetic and point multiplication and those things? Yes, exactly. The, well, the basic rundown of it is because in some cases overflow is undefined behavior, although in Rust it clearly is not, it's defined behavior, it just crashes and it rounds or in some cases it even just circles back. So just modeling arithmetic because people didn't expect that to happen, they assume that this means it's undefined when actually it's just unexpected behavior. And again, I'm not a huge fan of floating point arithmetic anywhere near anything that requires precision, but apparently it works. What I did was just offer sort of a middle ground where things that are definitely not unsafe are definitely marked as not unsafe and this is a simple guarantee and things that could be unsafe, i.e. they could lead to borrower checker violations which are already marked as unsafe, I'll give them a comment to the effective. Another person has looked at it and he said that it's fine. With unsafe there's not much you can do beyond that. That PR got merged, we no longer need to vendor the library as a result and we can use the latest version. Dalek is not that well maintained because one of the reasons why I originally had to do that was because they just have an outdated version of a library and the last blocking issue in order to publish the newer version of Dalek which was using the newer version of library was blocked by this issue. So I'm in favor of keeping 209 open and having someone who had a background in security having a lock, as I said, I'm merely a humble engineer. 213 is something which was opened by one of our engineers. Very likely I'm going to close it by doing what we're doing in our crypto library which is basically making sure that every algorithm including SCCP-256K1 does the same thing which is pad, shorter, seeds of bats. I don't know if that's the correct approach but this is definitely an approach that is used all through Altersa, making it generic and making sure that it's possible to amend it from one place rather than from several places is probably a better solution even if we need to change it later down the line. About cross-compiling, this is not as much a bug as it is a build question. I didn't remove the bug label because it can potentially be a bug. This was posted in September, 2022. A lot of time has passed and the person who originally posted this probably doesn't even have the same error message handy. So we can't really ask him to provide details into debug. But what they said was, according to the example of the use of CL, I cross-compiled with openWRTARM successfully but when I make it on my router, I met the segmentation fault which sounds like they might be missing a dynamic library. If under these circumstances, we've replaced, if A, we could trigger the segmentation fault and B, we could rewrite the segmentation fault to produce a human readable error message which says you're missing this library, then I think we could go from 213 to 14, sorry. Yeah. The rest are enhancements and a lot of them are open by me. So 206, 207, I'll fix those in 225 or 226. I'm sorry, 226 is already taken in a follow-up to 225. Sounds good. This is excellent. The last couple of questions I had, we've got 225, obviously. I don't, I'm not remembering if we had a determination on 217 and 220. I believe 220 is not necessary because of 225, but then 217. I don't mind merging it first. It does have one approval from you. I could give it another go and see if there are any conflicts. Like I said, 225 needs to be amended anyway because there are, because the pull request into Dalek got merged and I have some more bandwidth to update more than just the trigger dependencies. That means in theory, we could merge this one right away and this was open in January 17th. It's quite a long time. 20, 220, I think we can just close this one. I mean, we could just, we could technically rebase it and then merge it. Right, but if it's already being fixed by 225, I don't think. It doesn't hurt. It doesn't. From the point of view of statistics, I still need to make some changes anyway. For me, it's easy to deal with conflicts and it is to deal with that standing pull request. Okay. And 217, again, needs to be rebased. Thank God, Github added that button. Yes. Used to be like that. Okay, so from, okay, they have get random added. Okay. Yeah, not something I can review quickly. If you, as you review it and you feel it's acceptable, feel free to merge. Okay. And then the last one to look at is 228, which I looked at and it seemed fine, but no, obviously other reviewers. I think that this might be a bit of an XY problem. Okay. So let's have a look at revocation registry. Revocation registry just is a new type struct. And that's it. In these cases, you're not supposed to make the inner type public. You're supposed to add an accessor method. Okay. The reason why that's the preferred solution is because we have OOP, we have encapsulation. That basically, yeah. So what I would recommend doing here is not closing this public one, but actually asking Blueberry with the three why exactly do they want to do it? They, this is required for non-credits RAS as we use a different name for the key spec. Making it public makes sure we can just rename it easily. This does not create a breaking change. You know what? I think it's a single line. I just gave you why I might have apprehensions, but I think it's easier to do it, to make it public now. I gave it my approval, I'll merge it as soon as it's ready. Okay. Yeah, it's done. So we only have 225 and 217 outstanding. 217 I'm gonna review and 225 is gonna be updated and I'm ready for review soon. Should I get in touch with you via Discord? Or just get in touch with enough? It's actually more likely that I'll notice it through GitHub than Discord, so. Okay, I'll do that then. Sounds good. Excellent. Do we have anything else to talk about today? Not from my side. All right. Then I will make sure that we get the meeting time changed. I won't see anyone in two weeks. I'll be at the IETF meetings and otherwise engaged, but in four weeks, I'll see everybody on Monday. Sounds good. Thank you very much for the work. Cheers. Thank you guys. Cheers. All right. Goodbye.