Cool here you are guys Thank you guys for staying. I know that the weather is very nice outside and sunlight is limited So we have four projects up on stage you've heard them present There are some similarities between but not across necessarily all four although they exist in the same Family so I'm going to lead off with a few comparison questions, but divide them up here to the inter blockchain communication projects There's the obvious polka dot and cosmos. Could you speak together? One two two and one a little bit about the differences between the projects shared security versus independent security And will do you think over time these be collaborative or competitive? So on and so forth. So yeah Thank you for the question So like you mentioned that the most important difference between polka dot and cosmos is the shared security and the independent security side of things and then the second part is Upgradable chains the on-chain governance part of it basically the way we see it is that a shared security is needed as the way because One chain should not be competing with the other chain about security resources. They should not be basically Like doing the exact same thing with respect to stake or with respect to mining or something They should be collaborating on that scale and helping each other become more secure So if you are attacking a chain on polka dot a parachain, you are actually attacking the whole network and not just that particular chain and Secondly the other major difference is the upgradable Runtimes and the blockchain with respect to the on-chain governance is Nothing is permanent. There has to be an option to upgrade things. We are looking at right now There are so many use cases where we have to each and every day upgrade the smart contracts or upgrade the business logic or Runtimes and everything and then there is this huge Disruption of process happening because of that and we want to get rid of that whole problem by providing an on-chain upgrade solution so that's basically The way I see is the two major points of differences between cosmos and polka dot and why they are there Why these we are providing these kind of solutions with polka dot and I'll let Billy add to it Sure. Thank you So I understand why the comparisons made often in a way. We're solving similar problems But I think actually we're providing different solutions for different scenarios Polka dot wants to be a very large shared environment which has its benefits and also as a strawbacks We kind of take the approach that sovereignty is the most important aspect of any application specific blockchain and So we make that the the first available aspect of it when it comes to shared security. We also Try to avoid using this term We think it's kind of a misnomer what we like to call it is cross-chain collateralization which is entirely possible and Probably going to occur soon on cosmos and what that means basically is that? So there's chain a let's call it cosmos hub which has an atom used for staking chain B Could also use atom for staking as long as it's allowed to enact slashing conditions on that chain a's asset So if that were allowable then any of those validators which have atoms Securing chain a would be able to use those atoms to secure chain B as well This is basically an agreement that those validators need to come to with the second chain Which is again how we kind of see things happening. There's no reason you should be forced to secure a chain that you Don't agree with there's no reason that you should be forced to support something whose resources are draining on an otherwise productive ecosystem All of these things we believe should be sort of autonomous and taken care of by sovereign chains I'm also sure that you'll have responses to each other So we'll come back to a similar question a bit later on that will provide an opportunity there But to the graph and chain like this is sort of a similar question because Oracleization and data availability do have some similarities and overlap especially if you're providing the data in a decentralized way Could you speak a little bit to how the projects are distinct from one another and how you see them branching off a bit over time? Sure, I'm just one small correction is I don't think we saw the problem of data availability per se Usually I think of data availability is like a layer one concern Which basically means that like you're guaranteed that you'll be able to get the data that the data doesn't drop off that and and that's like an assumption that we make of all of our data sources and that essentially what We're solving is kind of quality of service. So it's I want to be able to access the data quickly and cheaply and securely and And so that's like a layer that goes on top if one Graph node doesn't send you a response. You can just hit another graph node. They're very kind of like interchangeable But then in comparison with chain link I kind of think of us is maybe like two sides of a coin or we're kind of opposite chain Like it's kind of a way of getting data on chain and we're kind of a way of getting data off chain So it's kind of cool They're both these kind of you could almost think of them as like layer two networks that kind of sit on top of You know these like blockchains and storage networks. Yeah, so Basically in order to achieve decentralization to achieve the type of ABT I think it's very important to have Something like basically you need in order to have decentralization to have as many actors as possible, right? So you need not operators who are providing this data to be incentivized and to have a reason to act honestly Basically to provide the data as I should provide it So not to lie or not to act maliciously. So in order to do this you have to have Mechanisms such as taking basically someone has Something at stake, right? So if you have a security deposit in tokens Basically saying all right if I start lying Well, the other nodes will show that I'm lying because they provide the right data. I'll provide the wrong one So I might get slashed, right? So you need to have kind of incentives for not operators to first act in a Not by Zentine way, I don't know how to say it and Also to keep their nodes running as much as possible So having the best uptime possible and that's also incentive So it's having the right game theory the right economic system in place to make sure that the network like this can function. Thank you very much Coming back to over here and we'll have a few that run across the board, but Talking inter blockchain connectivity communication Billy mentioned in his talk that the next big piece for cosmos was IBC Do you see standards evolving over time or will every IBC related project need to find their own way to Interconnect if you were at the Interchain conversations event the first question that Jay got on stage was When ether bridge so will will IBC possibly handle this over time across both projects or how will that shape up in your opinion? I mean, it's always difficult to judge any future scenario the way that I kind of imagine things happening with IBC I mean in a way, this also speaks to what what is IBC and what is supported with IBC and The first off I got to say that when I joined cosmos, I don't think I fully understood why cosmos exists And it took me a while to fully grasp exactly like what problem they were even solving and in a way I was really excited by somebody who's trying to solve a problem that doesn't exist yet But there was a lot of sort of early comparisons to between what polka dot was doing and what cosmos was doing in this idea of communication between blockchains and and a go-to factoid would be something like Cosmos will support transfers of balances and polka dot will support arbitrary state updates And in a way, this is true But what I came to realize later was that this idea of data transfers as message types So the first message type that would be supported with IBC is a transfer of coin This includes coins like non-fungible tokens though. So in a way, these are two message types And when you're talking about autonomous chains that are application specific In a way, the only part that really matters between those two are stores of value And so when you have a chain that's designed to do exactly what it does But it needs to sometimes say do something to some other chain almost every situation can be sort of Boiled down to a transfer of value But what I became aware of a little bit later as well is that so much of IBC is based on the work from a GORIC who's been sort of the inventors of the smart contract they've been working in this sort of context for 20 years and A message type that is very much on the runway is a call data Message type so this would be sort of a smart contract execution message type Which basically opens up any other sort of arbitrary state update Transition that that could be imagined through a message type I Actually think it'll be sort of underutilized though because of sort of the beauty and elegance that comes through the abstraction of Actual transfer of values between into chains where were the things that matter sort of arbitrary state updates Actually are already designed to take place on a single chain that they were designed to take place on So that's related to your your topic But do you want to steer it more in one direction or another or should I just hand off the mic? The question was really speaking to IBC do you think a standard will emerge over time that helps? utilize some of the science between the projects to to interconnect to each other back to Other chains Any repeat is the initial question sort of repeating the initial question okay, so so the To the answer like initially when Billy mentioned that It's still we cannot comment a lot on what's coming in the future. It's it's I fully agree with that On the other side like polka dot is already having a protocol called ICMP interchain message passing which is different from IBC and it Basically like allows arbitrary message passing now I'll go to go back to the one of the things that I mentioned in my talk It's like the infrastructure for infrastructure. So what ICMP is allowing for a chance to actually define? Standards on what kind of messages to be passed. It's like we are not enforcing chains too You should be only doing a data call or you should be doing only doing a coin transfer or anything it's like we are providing a base protocol and an infrastructure and the chains or the developers out there who are building their platforms and Frameworks on top of it are fully free to decide which kind of messages to be barge what should be standardized should it be Should there be a standard for a coin transfer should there be a standard for Arbitrary message or something like that. It's fully up to them to design and implement and come up with it Having said that There are other teams also who are looking into interblock chain communication like I was talking to some of them in this week And there is definitely like a lot of Overlap between these protocols and there are a lot of differences and it will be really interesting to see how we are able to you know Combine those overlaps and still convert some of those differences to reach Consensus on thought on that but still very early days. I would say Just quickly so I'm Excited to hear about this sort of process on polka dot which sounds to be mirroring a bit the process of IBC which is sort of Beginning with certain message types and working through what those message type support would look like on different chains I mean, we've also talked between the projects about the fact that polka dot would be able to support IBC if it chose to And be able to send messages from the polka dot ecosystem out into the wider interchain vice versa Your your sort of version of IBC is very much for communicating between different parachains, right? I'm curious what the design decisions are between IBC and your own version of it that are specific to polka dot that wouldn't be possible to sort of incorporate into Using IBC for all communication whether it was between parachains or to the wider interchain Sure, I'll be very quick actually on that because I I do not have that level of detailed expertise to compare IBC and ICMP, but what I can actually say is that you're right IBC will be just subset error layer on top of that if that needs to be supported in the future So it's still underlying protocol which can basically if we devise a standard Which has the standard of IBC messages then it they can still be passed among the parachains So that's how I'll just quickly close this So the topic tonight was interoperability and Coming back to this side of the Semi-circle How I'm curious do you react to this sort of answer you guys have spent the last few years with the projects? Working to sure bring data on and export data from the Ethereum chain Is this like starting over for both projects for each let's say interblock chain interblock chain communication protocol? Or would you benefit from a standard or is it simple plug-and-play? At the end of the day, I think it's it's very likely to be like a very heterogeneous Multi-block chain kind of world and we've kind of been prepared from from for that from the beginning We started with the theory and just because it has the most active ecosystem We really you know identify with the project, but I think Either way Software is going to run on a lot of different chains and so For us we want to like Organize all of the data from these different chains and we think that applications are going to utilize data from multiple chains And so actually like organizing that data It's it's not really like the classical interoperability problem All right, the problem that like cosmos and polka dot solve is much more round I want to update state across different chains And so for us there's an aspect of it where it's it's you know less tied to security in the in the sense that You know you can't make like a An incorrect state transition, you know using the graph But still linking the data across different chains So you know if you have like an interface and in your app you want to show you know all of the jobs that you can perform and You know those those jobs are pulling data from different protocols that are living on different chains You still want to wait a very efficiently get that data put it up on an interface and that's kind of the part of the problem that we solve Yeah, I mean a very similar like I think This panel and this stocks were great because we had two sides of the equation We had one side where it was interoperability between block chance and the other side between real-world data, right? So bringing this real-world data over to block chance now on our side like technically it's very different from the IBC, but and basically being able to communicate across blockchains, but Once we have put this data from the real words to block chain applications You also plan to be blockchain agnostic, right? Which means that we don't want to only have smart contracts living on Ethereum We want to have smart contracts living on Cosmos on Polkadot and all of them being able to communicate So I think having a standard there is a Very key. So we we all know about TCP IP and TCP IP was created by a consortium of enterprises businesses Researchers who kind of work together to create this standard and I think it's very important in the blockchain space to have Something similar like we can pull real-world data without having like with having Standards that are established, you know, and we need the same To kind of make this data flow across different blockchain networks. So that's very key to having Interconnected blockchain words where we can across we can communicate across zero year zero year words and block chance. Yeah Thank you very much. I have two more Quick questions, and then I believe Maurice will lead a few from the audience I'm going to move quickly to everybody's favorite subject token economics. So Or lack thereof so Quickly across the board and I'll hand off the mic so that you can sort of pass across Cosmos seems to utilize one system where heavily incentivize staking But it's not required Ecosystem wide if you move off of the hub or as Polkadot. I believe is the other side of the coin It's highly incentivize used to keep the Tire system interconnected in that way I'm curious to hear about how Going back and forth here chain links token Token economic model was I don't think it's something we're here about in this presentation and how the graph pulls off What you guys do without it? So I'll Let's go this way this turning basically we are relying on a decentralized network, right? So any decentralized network in order to establish trust we need Can have game theory and token economics to make sure that the actors providing the data are incentivized to provide it In a reliable manner, right? So basically the way it works with a chain link once Once everything will be kind of figured out on this side. So in a few months we start implementing Staking which means that people will or there is no date on this one But basically people will let we need to have a security deposit of link tokens to ensure that Basically they have something at stake right kind of similar to staking on cosmos and Tezos when you're Committing to saying that this state is the right one if you're providing data to the chain link network you need to have something at stake when you're doing it and Basically these data these oracles will be paid by the user's contract So someone who is pulling data from Noracle will have to pay this oracle using the link token So basically the more reputation you have so kind of first one the more staking the more staking you have It means that you have more security deposit so more to lose So your reputation is kind of more important right because you're more reliable in this way if you have more more at stake and second one Kind of people who have been providing so not operators who have been providing this data for a long time We'll have a bigger reputation which means that there will be more Likely to be chosen by smart contracts owners who want to query data from them so That's I think our token economics is very similar to any decentralized network that's using staking for instance like There are no like we haven't found the right approach. I think no one has it's still a space that's being explored, right? It's a very new space So it's kind of similar and we'll try to experiment and see what works. Yeah I think we've probably talked about our token Less than like maybe any other protocol that I know about we haven't launched a token yet But there is a token as part of our protocol design And that's just because we made the decision early on that we wanted to solve like pressing problems for developers And we would start with that first and that we would kind of decentralize over time So what we looked at today in the demo was us running our hosted service Well, we're running a bunch of the nodes and it's basically centralized All the code is open source if you want to run your own nodes You can or you could just rely on our nodes To make your life easier for now, but the goal is the decentralized network And so it's kind of this trust we're taking on with the community to say, you know We're starting with this set of problems first. We want to make it really usable we want to make life really easy for developers and You know, we'll be decentralizing as a subsequent step Along those lines at graph day is this event that we held in January We oh, we like published our specs for our hybrid network, which is the next milestone For for us and in the hybrid network Anyone externally will be able to run a graph node in part of this network. We are going to release You know the token in that milestone and and so we we published the The specs for this intermediate milestone where the graph is still responsible for some elements of security in the network But the economics are decentralized so you can earn money by running a graph node And basically the token has two uses in the network. There's a work token model So it's very similar to like a live pier for example If you want to run a node you have to stake graph tokens and that provides the economic security So if you misbehave then you're slashed and and then in return as a node you can set fees per query in Another currency like ether die, so we're explicitly not like a medium of exchange token and so this creates like an open marketplace where anyone can run a node set their own prices and that should make a service that's Reliable and and cheap For people and then the second use of the token is for staking on subgraphs themselves And so there's a few pieces in kind of like the governance and how we how we manage Essentially this global graph of data where people want to organize data and come up with standards for data formats in a way That's decentralized and so there's a governance component to that And then also there's like a revenue share component where if you stake on a subgraph then you can earn Some portion of the query fees for your curation work So those are things that are part of our our hybrid network spec Which is going to be the next phase for a protocol which is on our github at graph protocol slash research Cool, so as I mentioned earlier, I am a fan of this idea of like Decentralizing as there's value there if you try to decentralize too early and there's not value on your network It's it's a huge security vulnerability. You can attack a network that has no value So I really appreciate that spec coming from y'all In a way, it also has similarities to the way we think about token economics at Cosmos Because Adam is meant to be a staking token. It's not meant to be a store of value It's not meant to be a fee token right now Adam is a Cosmos is a hub that only has one token on it So it is used as the fee token But we want to make Adams as illiquid as possible Because that will make it as hard as possible to attack the network because if it's easy to buy One-third of the the stake that's on the network then it's easy to attack the network But if there's just not even one-third for sale at any given moment It's going to be impossible to accrue enough to make an attack like that So our primary goal is making the token illiquid One of the ways we do that is with staking rewards Which are very different from rewards on a proof of work mining where you think of getting paid for running your your node If you find the block reward, you know, that's your payday That's very much the opposite on on Cosmos We we mean it to be an inflationary token It basically means if you're not staking your token The value of it is dropping every second that someone gets a block reward because the the quantity of tokens out There is constantly increasing if you're not part of that increasing by delegating your stake to a validator or validating yourself That means the value your tokens are constantly dropping so that is supposed to encourage you to delegate them to stake them Lock them up do not let them be on the open market because if they're available that means the market and the network is unsecure The atom is supposed to give you rights as a validator to accept fees This is where we see the value of the network going through which is why we also very much depend on people wanting and using blockchains This is something that I like strongly believe in it's a time to finally test Like we have the tools and the ability to build scalable blockchains Now let's see if anybody wants to use them because if there's actual value out there those those Fees from that value will be what those validators actually want and what actually get paid from so Something like the one thing that I find very common in all of these token designs is proof of stake the world is moving to the staking side of things now and Now the thing is with polka dot we again have a proof of stake system But what we call it and it's how it is slightly different from generally proof of stake or delegated proof of stake It's like it's called nominator proof of stake basically or nominated proof of stake It's called N-POS and the way it works is that not everybody needs to run a node to get block rewards You can actually nominate a potential validator to act With your stake and they can stake into the network and run a node The second most important thing is when these validators join the network. They actually are Changed or shuffled every set period of time, which is called a session So they and at that particular time the block rewards are distributed. So that's one utility of the Dot token for polka dot that you stake your dot tokens to become a validator on the network And you can nominate your dot tokens for someone else to become a validator so that you can share rewards with them The second utility is getting parachain slots themselves. So you have to stake Dot tokens to get a parachain slot on the Relay chain and then you can actually be a part of that whole polka dot network Which allows you to participate into the message passing and the pool security and all the goodness of the relay chain There is no concept of gas or fee per se If you have a parachain slot, you are actually allowed to be part of the network processing the transactions along with the other validators and Message passing and in your chain yourself. You are completely free to How you want to have your token economics? It doesn't have to be if for example, there are use cases like NGOs and governments where you do not want your users to be paying for transactions They should be using your network as a as a free service then you are Good with that as well. You do not need local token economics in your parachain and in case you want a fee or subsystem or something like that For example, the smart contract parachain being built on polka dot called edgeware They will be having their fee concept inside their particular chain So it's very segregated and different on the polka dot network. It's the dot token doing all these several Things and being used for that and for a local parachain. It may not be something else. Yeah. Yeah. All right So the last one is a fun one You can keep it relatively short If you'd like there were two comments made up here one was that when they joined someone here joined their project they thought it was a problem a solution in search of a problem and the other one was mentioned by Okay, still fits the question and multiple people up here mentioned Not to speculate about the future. So let's do both I Hearing hearing these critiques. I'm involved in the Ethereum community. So I'm wholly unfamiliar but these Projects are coming of age right and while it may still be a few more a Insert weeks months soon trademark years Before polka dot v2 or phase 2 of serenity is online or IBC is live with lots of folks in the zones and Your projects have come to fruition Can you give a brief real-world example for either those here that may be slightly less technical or some that may watch this feed of How the project envisions its use in the future if Those things have come to mind for you and we'll go this way Sure So actually the vision of changing is really to replace detail agreements by smart contracts So for this we need a lot of data. We need a system of decentralized Oracle, which is secure, which is reliable I think a good example of how we see moves things moving forward is the integration We had recently with a Google which is going to use BigQuery Which is going to use chaining in order to pass BigQuery data on to the Ethereum blockchain. So that's I think yeah, I'm lucky because it was announced a few days ago and it's a perfect example We we aim to see a lot more businesses using chaining in order to solve problems that Can be solved with smart contracts. So DocuSign is another partnership we got their CEO is an advisor to chaining and We see a lot more enterprises using chaining in order to leverage the power of smart contracts Basically, it's in insurance, in finance and in trade finance. All of these fields will be very disrupted by smart contracts To be disrupted they need to transfer the data to the blockchain and they will use chaining to do this So if we're successful the graph will be like a global API For just like all the world structured information So if you want to build an application you go to the graph and you find all of the data that you need to build your app really quickly You deploy it and it just runs forever As far as kind of the space as a whole I really subscribe to the kind of sovereign individual sort of view of the world where you know Everyone can design their own jobs. You know, I could build my own custom application. That's just how I want to spend my day I clock in I find the type of Jobs that I want to do you know people are matched in this global open marketplace and And that's somewhat what the future of work looks like I recently asked Chris goes who's heading the research on IBC Would it be possible to run a single server validator that supported IBC? Because it made me think about sort of the original spec for HTTP That was supposed to support a standard for value transfer And they they just couldn't figure out how to solve the double-spin problem And sort of the the end game that I kind of see with the Internet of Blockchains or the inner chain is a Network an internet of computers where money is a primitive Instead of being a number in a database that is going to rely on a merchant service to redeem that value later on You just have a much more efficient computer system where money itself is as important as a Boolean or a string When you're programming and you can you can rely on this fact that money is is real in the software level and What's required for that is something like IBC, which is you know a standard for transferring value between different computation systems whether it's the most boring case say a single validator on a chain or a Public validator set on a public blockchain the idea that you could support that as a computer network is is where I think sort of the end game lies So for Polkadot It's kind of something similar, but it's in a slightly different way again if we are successful and we will be We are looking at basically a world which is more connected For example, let me give you an example for a real world There will be chains for doing very different things and doing them very efficiently very well if I want to book Book a flight and I want to book a hotel and I want to book in taxi And those are all being done on different chains There will be I don't have to like rely on their calling them separately or I don't have to Basically authenticate my identity for each of them. I don't have to make payments on each of them I will be basically able to do that Payments on one chain Who I am where is my digital passport on one chain and similarly booking a plane ticket and hotel on the other chain and so on So it's it's basically going to be a lot more connected less bloated and a lot more transparent when we succeed Hopefully, all right. Thanks everyone and I'll hand over to Maurice for a few from the audience ever many you feel you have time for There was one very eager center in the back here in the light shirt Sorry for being too eager I also think you led with the right questions you asked me earlier like what is the most important question I think sort of highlighting that difference between the different projects was very interesting But to this first topic like what does the standardization of IBC look like? And so so as a bit of like I worked very closely with tendermen back up to 2017 And we're launching like a first real-world use case in two thousand like in two weeks an application with like 25 million users But so I mean we're launching first to three thousand and ninety thousand and so but say But I mean we had to look at this problem Also, how do we communicate between side chains and Ethereum in it and so maybe it's more of a proposal like we you have EIP 712 and so what we communicate is hash data according to EIP 712 We store it in one contract We prove that it exists in the outbox on Ethereum mainnet and now we we pass whatever message So we have a message struct and then a specific type struct that sits in that message truck But we just use EIP 712 So maybe an idea instead of like trying to invent another standard there already exists on an Idea rather than a question. It's okay. Thank you so much Maurice to the next So this isn't this is also not really a question, but So there is a standard for IBC that's currently being worked on by multiple companies and actually At the last community call a researcher from Web3 foundation actually participated in the call So if you want to participate, then you're more than welcome to the there's a GitHub repo It's Cosmo slash ICS and then actually also the polka dot Wiki has a good explanation of it and then there's also right now for implementations Haskell That's being worked on Haskell JavaScript Rust and go cool. Thanks. Yeah, the meetup is also supposed to be kind of an exchange So that's perfect. Do we have some more questions? my question is more regarding like getting J data on chain and off chain and I'd like to understand because It seems to me that this is more or less a subset of just the off-chain compute environment And in both cases both in graph and in chain link you require having these decentralized networks And why do they always have to be separate? Why do you have to build the network every single time when you can just build a generalized application that requires for example in my case? I want inputs from five validators and That can be the five APIs that I'm requesting But also I can run it as many nodes as I want and I only have to run it on let's say the I exact network Why do I have to limit myself to a subset of API requests that I ever chain link or graph offers and not be able to write a generalized spec? Such as let's say a Kubernetes one Well, I think you're right that You know generalized compute is kind of a reusable kind of primitive But I also think that all of these different use cases have enough differences when you get down into it where Especially because we're so early in the evolution of these protocols They kind of need the ability to evolve separately because it's just really hard to coordinate large number of engineers together And so like even within a single team, you know, you kind of break things up into like modules or something right? You want to have something that's a small enough box that there's like one team or something that can like own that box And make changes independently and I think that the general concept of like protocols that are specialized at layer on top I think is a good one, you know modular I think is better than monolithic in general for these types of things Now as a node operator, maybe it turns out that you're an enterprising node operator And you say you know what I can actually ingest the same data From these like seven different, you know networks run nodes for these, you know Five different networks on top and I can do that really efficiently in that way I'll make even more money because actually, you know, the data ingestion part is very similar the data I have to store the computation Maybe it's like somewhat reusable and you can find a way to do that and I think people should Experiment and I think there's opportunities for those kinds of optimizations But as far as like the specs and the networks themselves I just think that like, you know, we're kind of building an operating system here It's like, you know, all of the different pieces are super complex and we just have to, you know Draw boxes around the various components so that we can kind of get it done Yeah, I fully agree with you. It's a very new space. It's very hard to define a generalized Application in this one. I think the modular approach is much safer and much better to basically for the future That's I fully agree with you. Yeah I have a question regarding the interoperability So currently when developing a web app, for example, and I want to use a single blockchain Then I already have this issue that I need a blockchain wallet I need some plug-in like MetaMask and now if I imagine that we have Pethora of different competing blockchains or need Yeah numerous wallets as well If I don't want to have the power at this central web app server, so have you thought of any kind of Yeah of Combined wallets that that allows you to Use those different blockchains from web as for example as well So I read an article recently from Richard Moore who if you don't know him is a great researcher mostly associated He's the major of ethers J s and a few different projects And he was writing sort of a speculative article about how do you future-proof your blockchain for the quantum computing? World and quantum computers are really good at doing very specific things, but not everything one of the things are really good is sort of breaking Encryption on private keys what they're really not good at doing is dealing with bit 32 mnemonic phrases So there's nothing that would prevent you from using the same mnemonic phrase on many different curve architectures And also it would sort of keep you future-proof from a quantum world I'm not sure which wallets are currently supporting Different curve outcomes from bit 32. I know that Cosmos supports the same curve as Ethereum the way that MetaMask handles it is slightly differently in order to sort of recover the Public key so there might be some tweaks there but somebody from MetaMask was here for the weekend at the Cosmos hackathon sort of supporting the the Grand goal, which I agree with you is is to be able to have you know a unified key management system across different worlds and and in a way this is I think the most important thing because Blockchains are cool and all but what's really cool I think we can all agree on is cryptography and what it's done is made a reason for people to care about strong encryption It's made a reason for people to have private keys to be aware of what they are to think about what that means to think about Multi signatures to think about all these really important schemes that are extremely powerful It's only until we have something that we need to secure Do we care about securing them and and I agree with you that I think this is sort of the most important component of No matter what blockchain you are it's where the the tires hit the road. It's where the humans touch the technology If there are no more questions, I would say Thank you and thank you all so much. Yeah, thank you so much for this great panel


In this vlog I'm sharing a rod during Duffer's fortnight with my old work colleague and long-standing friend Mark. The Mayfly are out in numbers. We've had to go a few hours in on the river Piddle and follow that with a longer session on the Friday fishing the river through. I've also got a very dodgy home-tied Mayfly collection that I'm keen to put to the test. So very briefly these are my river flyers. I've got my nymphs up here which is the larval stage of flyers. I've got present tail nymphs down at the bottom, gold-ribbed hairs here and in this box the huge budgerigar sized things for Duffer's fortnight. Then these are the small ones who've got large dark olives at the top, other little olives at the top. All the sedge patterns, when things get tough so we've got sparkle mats and some very small sedges. As he did all the travelling I let him have the rod for most of our late Thursday afternoon on the river Piddle. True to character, Mark was so enchanted by the first pull, he flopped it to a froth for a good hour. He wanted to stay, I wanted to move on. The joys and compromises of sharing the rod quickly came home to us both. He got his fish though and we were happy. Well done, good stuff. My gentlemanliness faltered momentarily and I got my fish, a good one. I smugly resumed my role as chaperone. I think we may have seen a fish move. My excitement prompted me to come out with a barrage of condescendingly useful tips and suggestions from my good friend.  That was that. Beer, late dinner and sleep followed. It's 70 mile per hour winds while he gusts into 2025. That cliff face gives us a little bit of shelter. Very nice. Mostly synthetic, isn't it? All of its synthetic materials. And those wings make the line spin, so using like five, six pound line. Did you say you got a little micro swivel came with it? Oh, it's plastic. Yeah. A plastic swivel. Right, that makes sense. These flood muddows are lovely, sparrows, sparrows, grass snakes, all sorts. Watch your steps. There's the odd hole here or there. So it's not like your typical chalk stream. It's not always clear, coloured bottom. In the trees, bit of cover. So the fly that I'm going to start off with is this creation. So this is the novice fly fisherman. Well, he's certainly got the length. I wasn't exactly committed, but then I wasn't exactly ready for it. Solitary fishing benefits my well-being. The best pleasures in life are nearly always the ones that we choose to share. One deal. I hadn't seen anything rise. I didn't actually know whether we'd get any rises, to be honest. No.  Like bad casting, lost fish.  Do you think you need to move over or over? I'll take a couple of steps. I don't want to get too close to it. Oh, my God! What a lump! Then there's the fish. The second day started off very well. Two rises from two fish in the same pool. Actively feeding on mayfly. I'm getting really excited now. It's ridiculous. And that was quite close, wasn't it? About the time as my fly line must have gone over that fish. Well, it looked like he charged it from the side, came at it from my side. One more crack at it. Further up and then change the fly or let it rest, change the fly. Can I have a cast here then? Yeah, absolutely. So I'm going to use one of my home tide. The bigger, the uglier and the more ridiculous the better. I'm going to go for that one. Which will make a mess of my lead, no doubt, but it's huge.  There you go, and he's in. And he's out. Bad. Justice. Oh dear, special branch. And lucky. Disfaithful behaviour, but I should have known better. Paul ruined, we moved up. After the exciting start, it became increasingly challenging. Fish didn't want to show, and those that did would glance, inspect, splash or shy from the fly. Alright, Mark has given up on this little stretch. I reckon there's a fish lying just there. Whoa, that's a tiny one. I think these big fly patterns definitely need a thicker tapered lead to turn them over. Yeah, it's sinking nicely under the surface as well. Did you put mud on it or zinc? The more it gets twisted the less it sinks. Paul is now, so he came through that pool. Two or three fish topped. He came up into here and they just stopped. Makes you wonder if they had that domino effect of spooking one. And it just ricochets upstream. I don't think we're sending a bow wave up or anything like that. There's enough water going through. Oh, is it in? Well played. I wasn't expecting that, were you? It's not, because it's about the third time I've put a fly on that spot. It's gone. Brilliant. It's gone, but that's good. That's called long distance unhooking. That is exactly what that was. That's the most technical form of unhooking. It is. I thought I've capped a little fish in, I did. So, over to you Chas. Thanks. That's the best thing about that unhooking fish is that it's by turn. It's your turn, unfortunately. Thank you. I like sharing a rod and showing the pleasures of the rises. Did you see that? That was a big fish, that was. I did feel like Greba did it. Mate, that was a good fish. You can see how wide it spooked, because look how shallow that water is. It's about a foot deep. Yeah. Moving up. Don't blame me. Now I've stood up here and see why I was wasting my time down below. There's three explanations that I hear most frequently for fussy and uncommitted trout rising to a dry fly during mayfly season. Number one, they're full up. Number two, they're wary from being caught. Number three. All the fish we saw topping were on that far bank in shallow water, presumably because that's where ephemera Danica are coming out of the silt, and they're probably eating them as they're emerging. See that rise? You're right on it. Come on, come up for it again. You deserve that fish. That was right on top of the rise, but I think you landed it as it was resettling. More often than not, with all the above in mind, I think it's about the presentation of the fly. A longer leader, landing it gently, avoiding drift and drag in the currents, ensuring the tipping is subsurface.  You may as well finish the job. Just get up there and catch something. I also wonder if spinner imitations or fly sitting high on the surface film represent a lower energy and nutrition value to the trout. Have a delicate presentation, slow it right down.  Because I think it's a heavy fly that it lands with a splash if you notice. Tricky though, because you have to sort of thump it through the wind, cut through the wind. Yeah, maybe a smaller. Much lower. Yeah, a smaller fly with less drag, less wind resistance will get you all to improve your casting massively. And your presentation. Yeah, exactly. Didn't even take it, just splashing at it. Crack on, Marks. I'm going to change my fly on that note. I'm going to change my fly back to the one that I started off with and take that big budgerigar off. Yeah. I might be in a merger all. After lots of fly changing and discussion about the ethics of whether Mark should put on a nymph or not, I eventually managed to catch a good fish on an oversized parachute creation. But Mark's confidence was waning. Okay, on. The Alter Ego Super Guide re-emerged. Show that fly. We had taken two rods to avoid arguing over choices of fly, but only used one at a time. If you want to have a look at my fly box, you're very welcome. Getting rises on those other. Yeah, but they're slappy rises, aren't they? Go past it if you want. Go past it or go and retrieve it if you want because it's not like we were short on water to fish. Change fly game. Just a little over it. Come on. They've just got their heads down, I reckon. I don't know. Seems a couple of fish topping up there. What are you changing to? Your nymph thing. Really? You want to do that?  Yourself, me, you. Seems to be extreme. Stinging it was on my ears. Sun's gone out. Okay, sun's back out. Wind's dropped. Wind's dropped. We need as big fish to rise. Yeah, rub it in. Yeah, you would have thought so, wouldn't you? There you go. Oh, it came off. Tossed about to miss, Bratt. There'll be plenty of other big ones around the corner. Yeah, I've seen plenty of them. And two on the right-hand bank as well. There you go, I've got one right here.  That really ought to get a take. Yeah, there you go. Careful. Taking it around the corner. Fish. It's a bruiser. That is an absolute tank. I'll follow him to the net. Well, if I was American, I'd give you a high five. But I'll just say, well done, old chap. Beautiful fish. Well done, Mark. Get your hand down away from the tail. There you go. Lovely. Let's take a bit closer up. Yeah, well done. Let's get back. Really cold now. I guess I ought to warm up and put my Adam's smile on and sort out the tippet material. I'm using some Fuller's clay with a tiny dab of washing up liquid in it. It helps to sink the first few inches after the fly. And the other thing I like to do when a fly gets drowned like this is to give it a good old squeeze in it and undo mushroom.  Well, I just got out of the water because I was getting cold and in that time my phone has run out of memory, so I couldn't record, and Mark has just caught three fish in a trot when I have my little drink, including this one. That's a cracker. Well played.  Pretty heavy. Well done. What was the take like? Fish. Yeah. I took you into the... I thought you were going to lose it at one stage, actually. Wicked. Nice to see you smiling. Glad you didn't go home. Yeah. A maheken. A maheken. It's not one I tied myself, but available from... They're actually called maheken. Yeah. So next up, I'm going to fish an Adam's fly. Oh, am I?  Lots of fingers. No, no, that's fine. I've had my fix in our car. I've fished for three minutes. I'll let you carry on again. Cheeky bugger. When are you going home? I'll change to the Adams. There's a lovely wild eat, and I need to get it back. Where do you go home? About an hour. About an hour, okay. Good. Good then. So does that give you some sort of priority, does it? Because you're going home in an hour.  Well, you think I'm staying on till nine. You know what's going to happen. Lots of fish. I know. I don't know why. Right, well, I'd better go. This is a glassy pool, isn't it? Classy, glassy pool, yeah. Oh, that was a fish. What do I move it for? Not interested. It's a bit better. The thing is, I think the actual roll cast spooks fish. Do you reckon that fish is actually that close to the bank still, or is it just moving around loads? No. It didn't look like a particularly big fish, did it? No. It could have even been a mayfly coming off the water. The ripple is so small. Well, if it was a pool where you'd think you'd get a fish, it'd be under here, wouldn't you? Mmm. Well, there ain't nothing out that natural. Do you want to have a crack on the... underneath the next overhanging tree? Come on, guys. It is where that fish topped, isn't it? There you go. It's on. Nice fish as well. It needs your net. Staying deep. Getting quick. Yeah. That one's going down, River. Good gun. I need a bigger net. Well, it's gone then. That's the biggest of the day. That's probably my best ever while. That's probably my best ever while brownie. Brilliant. Right, now you can fish for as long as you like. That's the biggest while brown trout I've caught. Biggest while brown trout I've seen. Cracking fish over the moon with this. That for a while, fish. I think my best brownie. Wicked. Just getting back. I would kiss it, but... That's a beautiful fish, mate. Wicked. Cheers. The fishing today has been great because there's been plenty of water to cast to. The piddle yesterday was probably difficult because the gaps between the renunculus weed were quite narrow. Mark has to go home, but he's going to carry on fishing until he reaches that bush. I'm not sure I could share a rod with just anyone. They would have to put up with me for starters. I'm a stickler for rules to the point of being a bore. I also don't like obsessing this about sizes of fish, numbers of fish, or fear of blanking. I'm not very good at just staying quiet either and keeping my opinions to myself. Cast here, cast there, look behind that bush, look for the crease, change of flight. I have good fishing friends who I would never dream of sharing a rod with and one or two friends who I've vowed never to share a rod with again. Sometimes it just doesn't work. You need to have similar outlooks to your fishing. It's a bit like sharing a boat, especially when it comes to making joint decisions. I've fished with Mark for a couple of decades now and used to work with him. And although we've disagreed when having to make joint decisions, we've always got on. And our foibles come as no surprise. I can't wait to get in the warmth. Really cold. Cheers for coming down. It's really good to me. It turned out alright, didn't it? I was really nervous. Well sometimes it can be too nice, can't it be too nice? Well thanks goes out to Mark for another great moment shared.


The best way to be able to gain information about the enemy that we're facing is to be able to be on the ground, be moving through the terrain and gaining information. We had a few things lead into an air assault designed to pick up, push miles away, get dropped into a beach and defend their shores. You've got squads working independently, air inserting behind enemy lines, moving forward identifying the enemy's positions on the ground, moving in and destroying the enemy COC and integrating engineers and demolition and then pushing past that objective, integrating with our 60s and 81s, our forward observers and also a squad of medium machine guns. They're all inserted as part of Wave 1 and they're supporting the second part of the attack. The second part of the attack is a seizure of the enemy fuel facility. The importance of that is that it's not the typical objective where you're destroying the enemy in place. You actually need to be able to retain the terrain and the fuel facility that's on it so that future forces can move through the area and use the equipment that's on the terrain. Then the last part of it is creating a defense in depth and defending against an amphibious counterattack from the enemy.


Hello. Welcome to Making a Movie with Wikimedia Commons. The story of the last line. This is a lightning talk. It will be fast, it will be short, it will be punchy. And it is the story of how I made a short documentary using incredible resources from Wikimedia Commons. I'm really excited to be with you all. I hope that if you've made a film before, you are thinking about making another one, and you're going to make it with Wikimedia Commons resources.  Let's go forward. My name is Zach McCune. I have been a Wikimedian since 2005. And today, I work at the Wikimedia Foundation as the director of brand. I'm also an artist and a filmmaker, a graphic designer. I really try to work as much as possible with free to use public domain and archival material. And I also try to release the things that I make as public domain or Creative Commons assets. I endeavor to emphasize the word creative in Creative Commons. And this image is from a conference that happened in Shantagar, India. It was an amazing opportunity for me to travel there when I got to teach a short introduction to photography. So that's why there's so many cameras in this image. Since 2019, I have been making short films from archival material. This is material that may be in the public domain or released by government agencies. It might be work that has had a copyright expire. And fundamentally, this is fun work to make movies from because it's kind of forgotten. People have failed to remember the stories that are embedded in all of this old footage. In each of these three films, I've crafted a story. I've cut the material together. And my amazing fiance has created the music for them. She's put the compositions together so that they have incredible soundtracks. We've been really lucky to get these films into 11 film festivals in seven countries and counting. Unfortunately, we have never been able to attend any of the film festivals because of COVID-19. So like this conference, a lot of these film festivals that usually would be in person happened instead online. Now, let's talk about Wikimedia Commons. At 87 million free-to-use files, Wikimedia Commons is the world's largest free-to-use collection of audio and visual materials. It's just an incredible resource. And every day, people put more and more stuff into it. Incredible images, great archival material, incredible videos, audio files. It's just amazing to see the things happen. Wikimedia Commons is most often used for Wikimedia projects. Things like Wikipedia, Wikivoyage, and Wikidata. It's used most often within our own system. But I want to tell you Wikimedia Commons is also an extraordinary resource for filmmakers. And I'm going to tell you a bit more about how I made a short film recently, almost entirely from Wikimedia Commons material. The story begins right here. I found myself on this Wikipedia page in December of 2021. It tells a sad story about a lion subspecies that has gone extinct in the wild. Hidden on this page is this incredible info box. An image with this caption. It's about the last photograph known of this subspecies. And it included a link for the photographer, Marcelin Philandrin. Like any other Wikipedia reader. Here's what I found. I went ahead and clicked that link. And I found a short Wikipedia article on English about Marcelin. But better. I found on Commons a world of his creative work. Things that had entered the public domain and been digitized by Wikimedians to be accessible for anyone anywhere in the world. Marcelin's imagery documents Morocco in the 1920s and 1930s. He took photographs from planes, mostly, but also loved to take photographs on the street and on landscapes. As I'll tell you, and you'll see in the film, he also had a penchant for taking photographs of more adult subjects. New images, erotic images. Things that we might even consider pornography today. When I couldn't find images from Marcelin Philandrin, I actually went searching through online archives, libraries, bookshops, and more to purchase original works by Marcelin Philandrin. And when they would arrive, as this one did in February, I would go ahead and add it to Wikimedia Commons by digitizing it myself. In fact, I'll show you, I have a book of his work right here. And in this book near the back is something really beautiful that I found, which is a photograph of the photographer himself. It's just gentle, so I'm going slow. Here we are. Here's Marcelin. So I bring it into view for you all. This is the image now on Wikipedia of Marcelin Philandrin. We didn't have a photograph of him. I found it in this public domain book. I digitized it and added it to Commons. Overall, I collected 20 images of which 17 were from Wikimedia Commons. That's 85%. And I put them into storyboards, like you might for a slide presentation, and I wrote a script to guide the whole story. I hired a narrator to read the script, and my partner, my fiance, she crafted a musical score to accompany the work. It all came together when we premiered the film in April of this year in San Francisco at the Green Environmental Film Festival. We were delighted, honored to premiere it there. And we have two more places to premiere the film so far. One in New York City and one in Los Angeles. We're really hoping to show up more places in the world. And after we finish screening it at festivals for people who love environmental topics, documentary topics, we'll do what I have done with the other three films, which is release it online for anyone to see and use and borrow from. With that, I'd like to call to the audiovisual experts. I'd like to show you this film. I'd like to do a premiere here at Wikimedia for the international premiere, the worldwide premiere for anyone who wants to see this film, not in one market, but anywhere. I'll go quiet for three and a half minutes as we watch this film. It is a haunting image. At the end of a long rocky canyon, a single lion stands facing the sun. It's a male. We know from his mane. And because the lion was photographed high in the Atlas Mountains, we know that this is a barbaric lion native to this region. This image is from 1925. And it is the last come from siding of a barbaric lion in the wild. The photo was made by a man named Marcelin Flandre. He was born in French Algeria. During the First World War, he learned how to take photographs from planes. In Casablanca, he applied his skills to city scenes and landscapes. He was Morocco's first aerial photographer and innovative image maker. He sold books and postcards. He offered portraits and commissions. He also made porn, exploitative stuff, with an orientalist view of North African women. But mostly, Marcelin is known for the lion. The barbaric lion lived across North Africa for millennia. It was hunted by pharaohs 3,000 years ago. It was the lion feared by ancient Rome, used to fight gladiators and in public executions. When people say, throw them to the lions, they are referring to these lions. Framed as the ultimate killers, centuries of hunting eradicate the subspecies. Marcelin was 46 when he joined an Elmer flight from Casablanca to Dakar. We can only imagine the trip. How long were they in the air? What was the route? When did he notice the lion? Did he take multiple photos? Was the lion really alone? We do not know. We do not know when Marcelin realized he had captured history. We cannot rescue or recover the barbaric lion. And yet, thanks to Marcelin Flamre, we can still see it. A lot of the questions were about the source of the material. So it was a chance for me to talk to film lovers and filmmakers about Wikimedia Commons and how much is available there. So I want to say here, just as I said at that moment, that this film would not be possible without Wikimedia Commons and the people who digitized work and added work to that incredible global repository. You know, well, sometimes we don't know where the work that we're making is going. I wanted to celebrate those folks who have taken time to contribute this archival material from around the world. Because, you know, with Marcelin Philandrin, the subject with his passing, the work became distributed around the world. Just as I have some of it here and it become a Marcelin Philandrin collector. And thank you all for the kind notes in the chat here. I will pass on the credit. The music, I think, is much stronger than the film. It's a whole different topic. If we can go to the next slide. I don't know where we are. Yeah, there it is. Commons made this possible. Let's go forward one more, please, on the slides. Let's see if I can get us there. Perfect. I want to let you all know that I put all the images that are on Commons and in use in this film here at a page off of my own Commons account. So if you want, there's the short link there. You can find some of these works. They're from Wikimedia Commons there in case you want to make use of them. And in particular, of course, that postcard, the postcard of the last Barbary lion. That's an extraordinary, extraordinary, I mean, very evocative image. It truly is haunting. And that's the entire story really centers on that. Overall, I want to come back to the power of Commons. It's a platform that people are always adding their points of view to something that makes us understand and see the world better every day. And I know that it has been so vital. It is the core of so much of the visual knowledge work that we do here in the Wikimedia movement. But I want to celebrate the fact that it can be a creative resource as well. And in the future, we may be in a position to offer it to creators and filmmakers and see what they do with it. I get kind of excited thinking about a possible build on the wiki loves work as something like filmmakers love wiki where they actually show us what they make. With these resources. Thanks so much. My name is Zach McCune. It's been great to be with you. You can find me on my talk page or you can draw me an email. Really appreciate your time. Have a great wikimedia.


As you said that sleep means close your eyes and unaware and meditation means, okay, close your eyes but be aware. Can we do with regard to this, can we do the meditation with open eye? Once there was a Sufi master, his name was Ibrahim. In Ibrahim's ashram there were many people. One day two disciples met in his garden, in the garden, the ashram. Both were a little frustrated and both of them said, I wish we could smoke, they want to smoke but they're in an ashram. So then they talked about it for some time and said, why don't we go and ask the master, can we smoke? They decided to go and ask him separately. Then next evening one man was again sitting in the same spot frustrated. Another man came smoking, hey, you're smoking. How can you smoke? Master told me not to smoke. What did you ask him? He said, I asked him, can I smoke when I'm meditating? He said, no, how are you smoking? He said, that's your problem. I asked him, can I meditate when I'm smoking? He said, okay.  No. With eyes open, can I be meditative? Yes. But in my meditation, can I open my eyes? No. Okay? In fact, the Samyama we are talking about, you know, we mentioned something about Samyama, yeah. The Samyama meditations are basically to train you to become, to meditate with eyes open so that 24 hours, no matter what you're doing, you're constantly meditating actively. With eyes open, in all the activity that you perform, you can become active meditation. Then it's a different world by itself. So, Samyama meditations are for that purpose, to train you to open eyes and meditate. But don't attempt shunya with eyes open.  You open your eyes, where all you will go.


Welcome to All Hands Update. I'm Petty Officer James Stilpeck. The Navy prides itself in the diverse sailors and marines who serve around the world. The Language, Regional Expertise and Culture, or LREC program, maximizes our capability to maintain the Navy's global mission. The Center for LREC Office provides online and resident training, as well as several other learning resources for sailors and marines. These courses provide students with the cross-cultural skills needed to enhance relationships with our global partners. LREC can also ease the transition to a new location by helping sailors and marines learn about the new region and culture. Sailors can also access a large library of language skills courses, covering everything from Arabic to Zulu, to aid in communicating with our partners around the world. Visit the Navy Personnel Command website and look under Career Info for more information about the LREC program and other learning resources.


Good afternoon and welcome to this talk about tracking vulnerabilities with built route in Yachto I'll first say a bit about myself. My name is Arnaud. I'm an embedded software architect, but that's just a title So I work in embedded software as a consultant Focusing on Linux operating system integration So the the lower levels of the operating system which includes some kernel work, but mostly integration work, packaging, things like that And as a consultant I've worked for many different customers in all kinds of domains multimedia security, home automation, satellite communications, satellite GPS telecommunications Bluetooth I'm probably forgetting some domains as well Also, I'm a maintainer of the built route project which explains why I talk about built route in this talk But for my customers, I also work with Yachto quite often so I can talk about both here So what am I going to talk about? First as an introduction, why do we track vulnerabilities to begin with? I Hope I don't have to spend too much time on that And then about the infrastructure that exists in the world for tracking vulnerabilities Basically CVEs, then how it's done in built routes, how it's done in Yachto I'm starting with built route because that's what I know best So the Yachto part is going to be a little less in depth and then finally an alternative which is tracking vulnerabilities with a software bill of materials And then finally some evaluation. Well, actually the evaluation is During all the rest as well So why track vulnerabilities? Is there anybody who feels that I should even discuss this? I think I put some reasons in there But I think for most people it's obvious that we need to be aware at least of which Vulnerability exists in the products that we make Although what I see my customers is that it's not done. That's conscious conscientiously I expect that this is going to become more and more important. So on the one hand we have Because devices are getting more connected We will see more attacks and they will eventually hurt sales and then then suddenly it's important, of course And on the other hand, we also have regulations coming up. So in EU is discussing regulations that among other things also require products to be to some extent secure Now what is Important is that we want tracking. We want to track vulnerabilities after the product has been sold already To be able to fix things after the fact So it's not just at the time that we build the product. It's also afterwards that they need to be tracked It's also important to realize and this is a slide I stole from a presentation this morning That's So second is one piece of the Security jigsaw, but also tracking vulnerabilities is one piece. It's this piece here So it's a very small piece of the whole but a necessary piece So how can we track these vulnerabilities? The first thing we need is a way to be aware of vulnerabilities One way to do that would be to do constant audits of all the open source enclosed source software that you integrate in your product But that is not feasible And because everybody in the world is this problem a Kind of solution has been created in early this millennium Which is called the common vulnerabilities and exposures So CVE is a is basically a system for identifying vulnerabilities. It's basically an It's not much more than than an ID than a number So that's the main Purpose of the CVE and then there's a database of vulnerabilities. In fact, there are several databases of Cve's the most Central one, let's say is the NVD the national vulnerability database Which is maintained by US governments Institute called NIST so they provide a server which Provides access to this database They also you can send a mail to them to say that there is something wrong in their database and it needs to be updated But it's not the only database. So there are other databases of Of all the vulnerabilities, but there are also many more specialized databases For instance, all the big distros have their own databases of Cve's which are Typically copied from from the NVD database, but only the ones that apply to them. So which are So any anything we know is only is not going to appear in that database Now with the Cve, you have an identifier of a vulnerability And then there is some free text description of what this vulnerability is but not really much more than that It doesn't allow you to identify what is the thing that is vulnerable and so It started with a bit more formal description of how The contents of the Cve should be structured But in I think something like 15 years ago a more formal Definition has been made and that is the Cve the common platform enumeration Which They have different terminology, but basically which allows you to identify a package And not just a package also a version of that package So the way it works is that Cve is a number with a more structured number With a bit of header They're already at version 2.3 because it's already from quite some time ago. And then you have a vendor and products in a version and then there's some more fields which are basically never used So there's also a database of all these products and all these versions that exist or for which Cve's exist and This database is maintained by NIST as well So also to that database you have web access and Command line access And so these two are linked with each other so every Cve has a list of Cve's to which it applies the original idea was that Every time a vendor releases software They also create a Cpe entry and so that entry is added in the database and then when a Cve is Created They enumerate all the the versions to which it applies Turned out that that didn't work very well So eventually they come up came up with also a way to specify a range of Of versions basically larger than and smaller than And then you can have several Cpe entries to which the Cve applies. I have examples a bit later Unfortunately the this Cpe thing does not work that's great Most of the reasons that it doesn't work is actually because it's from a time before open source software was was really popular And so it's not really Applies well to the open source software of today So one issue is that software packages sometimes don't even have releases So you just have to leave it had and and take some random In git commits and there is simply no way to track that in in the Cpe database The the version comparison simply doesn't work It also doesn't take into account patch versions so in theory if you have the Like open as a cell the upstream version And then the one patched by Debian and the one patched by redhead and so on and so on There should be separate Cpe entries for all of those but nobody does that so you basically have one Cpe entry And you don't know if if a specific package that you have if that Cpe entry applies to it or not It's also a bit cumbersome to create them so in theory you have to every release creates a new Cpe entry and The worst thing is that there is no link to the actual software. So it's just an identifier again which for for The close source World was logical because you you didn't have a git repository to point to But for us we want to actually link it to Release star ball or a git repository or something physical, you know, not physical, but something we can touch And the Cpe doesn't provide that And In addition the information in the Cpe database is often incorrect Fortunately, it's fairly easy to correct it So we can't make a pull request But at least you have a contact form where you can fill in the reasons why the Cpe information is not correct And usually within a day or two they will fix it then so here's an example of what the Cpe looks like in for a real Cpe and why it's not correct so the Here is a list of the Cpe IDs to which it applies. So we have several Configurations and then in configuration two we have two versions to which it applies And all of them are wrong actually So first we see here that's in a description. It says before to 228 zero and before 3.0 but then in Here it says from to 220 up to 310 so the before 228 zero is completely dropped from this range. So if you have a 228 zero It will in fact match that that Cpe entry as you think that your Your software is vulnerable while actually it is not The reason that this happens is because at a time that the Cpe entry was added to 228 zero didn't exist yet and Nobody thought of updating it afterwards And then the Fedora thing is also wrong because in fact This this issue was fixed both in Fedora 36 and 37 so the 36 and 37 Doesn't say whether this is Fedora 36 at a time of first release or with all security patches applied So yeah, it's it's kind of useless information as well Still is the best that we have So we will we will use it in In built route any octal so let's take a look at how it actually works in built routes the command to track vulnerabilities is very intuitively called make package stats The reason is called that is because it's a bit historical There was a package that's comments already and then somebody sits. Yeah, I also want to do CVE tracking and Yeah, we can easily add it there. And so package that's got extended to it with CVE tracking What does this command do? Well, it doesn't actually do it in make it calls a Python helper to do the actual have a lifting It will download the CV and CPE database as JSON files and just save those JSON files as disk and those are cached for 24 hours Because the downloading all of that takes a couple of minutes. So it's useful to catch it Unfortunately, there's no way in the In the NVD database to ask for everything that changed since yesterday so They're the only way to update the cache is to download everything again And and unfortunately also things can change even in very old CVE's because maybe the CPE entry has been updated So, yeah, you can't just say I only download the ones from 2023. No, you also have to download 2009 again second the Selected packages. So the packages that are selected in the configuration file of built routes Are cross-referenced with the CPE database? to to see which versions match and then these are Sorry, these are referenced in the CV CVE database to see which CVE's apply to them And then finally some exclusions are applied to it I'll come back to that why that is and the result is written to JSON into HTML The HTML I can make a demo There is my demo so there's the HTML outputs. It's not important that it's not readable I'll just say you have the package name What you need then is a version number and then here is all the CVE information Here is the CPE identifier, which is Determined by built routes if it's green it means it's a valid identifier It exists in the in the CPE database if it's red there is something wrong with it So in this case, there is no corresponding identifier in the top case the Linux Linux kernel identifier does exist, but the version number doesn't exist In in this nice interface with JavaScript We can actually sort all CVEs to find all the packages which have some CVE applied to them Otherwise this HTML is not actually very useful So it's good for showing in a presentation but and also for manually looking at it But if you want to formally do it, you you will need to use the JSON files and I'll come back to that and so Went over this then the exclusions I didn't mention exclusions yet. So one column is also the exclusions which have been applied so the The box in orange is the list of CVEs Which apply to that version in which have not been excluded the exclusions They are added for various reasons the most important one is because build route carries a patch that fixes that CVE But it can also be to due to other things like the issue doesn't exist in build routes because for instance like the Open SSL random number generator issue that was in Debian That's an open SSL issue, but it only applies to Debian. So then we make an exclusion for that one or the vulnerable code is never even built in build routes for instance in Some packages I can't think of anyone immediately, but have several packages which are in a single Which are in under a single product So in the in the CVE database, but build route only uses a part of it And so then only that's well anything which which applies to the rest is not included And now it's nice to have this list of CVEs, but it has a bunch of limitations To when you want to use it in practice and all these limitations actually Come from the fact that this was created more for the maintainers to see okay We have to update build routes in and apply Patches to fix the CVEs not so much for vulnerability tracking by a user So what are the limitations? One limitation is that you have to explicitly do make package stats, but okay, that's not much of a problem So it's not always there. You have to explicitly ask for it We can't really do it always because downloading the database takes quite some time. So Also the information reported does not contain the CVEs analysis the severity analysis now My opinion that analysis is usually geared more towards Like cloud applications and for your typical embedded application or when you use build routes It's not so relevant. You have to anyway reevaluate for yourself what what the severity is More importantly, you need the full build route source to generate the vulnerability list. So you can't once you've made a build The the build artifacts does not contain the information that you need to regenerate the CV list And you will need to regenerate the CV list after the product has been released. So that means if you afterwards want to To to check are there any new CVEs that have have been created which apply to my products Then you will need the full build route source again You don't need to do a full build you just need all the sources That includes the Package definition custom package definitions But actually only if you want to check CVs for door for those if you don't want that then you can just leave those out But well, it's not not a big deal to include them as well There's no separation of built-only packages Which means if you use for instance open as a cell during the build to sign the kernel then This is also the vulnerabilities to open as a cell are also included Even if you don't have open as a cell in your target device So it's looks at first sight. Yeah, but then maybe we should leave out open as a cell on the other hand It's very all possible that the vulnerability still applies to the signing of the kernel. So it's Maybe not so bad. That's that's even those builds only packages are included But then if you want to maintain that CVE list later You will do an analysis of each CVE and in many cases you will determine, okay, this CVE actually does not apply to my products for instance There is a vulnerability in some encryption algorithm that is not used in my products or there's a vulnerability that Only applies in a certain configuration and in my configuration is configured differently. So it doesn't apply So it's not possible to To add these exclusions later without modifying the source But for a release you don't want to modify your tagged release after the fact. So that's a bit tricky case also, there's no way to Or it's difficult to record configuration specific exclusions But so it's still possible to use it in practice and how do you do that? you Situps your CI to not only do builds but also generates the vulnerability info and then you just ignore that vulnerability info At the time that you're preparing a release Then you're going to evaluate the vulnerabilities and if necessary patch them but For many cases you will just documents. Okay, this has been evaluated as not applicable or it has been available evaluated as low severity So only if there is really something that needs to be patched you do the patching and then after the release you regularly regenerate the vulnerability info on the On the release source code. So you tag your release and then you make sure that there's a weekly for instance CI job that runs on that release stack to generate a vulnerability info and then you sometimes have to check Okay, what's what are the difference between the last time I checked are there any new CV is? And then update this manual documents manually update these documents to see what is Well to evaluate the new issues Now in Yachto in Yachto, it's actually quite similar So the technical aspects differ a little but it uses the same approach of querying the MVD database so You do the CV check by just adding inherit CV check to To your configuration file and then you typically also do include extra CV extra inclusions extra exclusions That's for this the CV exclusions that bilter it also has has in Yachto there most of them are put in a separate file And so what does you have to do then it's also done as a CV e database, but not a CPE database and then it's goes to it looks at the CV product defined in a recipe and Looks looks up everything in a CV database that matches it So it doesn't look at version at all. It only looks at the product and Then after it says collected all of this then it goes to each CV and checks the version With with greater than smaller than matching and if the version doesn't match then It says okay. It's already patched or if there is a patch filing Yachto itself, then it says it's already patched And you can also specify explicit exclusions like in that extra exclusions database and Then it's marked as ignored and so you have a the result is a per package system file with All the CV is that apply to the package at in any version and then for each CPE whether it's patched or ignored or vulnerable So you always need need post-processing to to use this there's also a text file, but it's useful because the chasing is easier to post-process So here is an example what it looks like don't worry too much about the details It's basically contains all the information that I mentioned. It also includes the Cv s CV vs forgot the abbreviation the The vulnerability score In some other metadata Yeah, that's about it. And so as I said the whole list so for Linux we have a thousand CVs I mentioned all of this The limitations are mostly the same as built roots, but just And for the same reason so it was created mostly for maintainer and List so for for a user that wants to track after release What is a bit worse is that vulnerabilities are generated as part of the build So you really have to do a full build to get the vulnerability list In you need all the layers again The exclusions are in the source code again The advanced I mean compared to built roots you do have the vulnerability score so that's an advantage of the Octo approach and yeah, also because the the version matching in Yocto is not done with the CPE database. It's actually a little simpler You need additional tooling, but you also In reality also need the additional tooling in built roots So I gave a lot of disadvantages So I wanted to see if there's something better in we have this software build materials So I checked if that was usable to track vulnerabilities it makes a lot more sense because You can generate the S-bomb at build time and then after the release you can just use that S-bomb to check if there are vulnerabilities And there's also a Google security blog that explains why this is a good idea And it refers to two tools that can be used to do this to from an SPDX S-bomb get a list of vulnerabilities Fortunately, yeah, maybe I should first mention what OSV is I'm running out of time. So this will be very quick It's basically an alternative to the CVE database that tries to solve the issues that the CVE and CPE databases have So it will accurately track the upstreams with actual links to the source or links to the release star ball It also has Version matching that works so you can you can use git commits to do version matching and it will look in the git history to see which whether a specific Git hash is vulnerable And then to make it easier to add vulnerabilities Bitless administration they define ecosystems and each ecosystem manages their own Vulnerability, so you have ecosystems like pi pi npm, etc You also have distro ecosystems alpine almanium exdebian and we have OSS first so completely different ecosystem that takes packages from everywhere Unfortunately each of these ecosystems have their own way of identifying packages. They're compatible with each other, but Yeah, not necessarily And then they have a lot of tooling to work with this Unfortunately the existing tooling doesn't work Why doesn't it work? Well for built-root built-root currently doesn't generate an spdx sbomb And then the one that the octode generates is not compatible with what the the two tools exist basically It's very simple you octode generate something with a cpe But the osv tools don't use the cpe identifier So that part is useless and then you only have the the name inversion info and the two existing tools don't look at those fields They look at different fields It's fixable it just doesn't work out of the box, so I ended up not using that so I can't say much more about this There are a number of other theoretical problems with osv So I mentioned already you have these different ecosystems Which are responsible for for Adding the vulnerabilities and the result is that you don't have all vulnerabilities in osv So in I did some numbers in Cve you have 31 1000 Cve's and in the debion ecosystem for instance you have only 9,000 OS fees of course Cve's are for everything including Sorry, you have 31,000 Cve's which are tracked on debion org Yeah, so these are things which apply to debion, but still only 9,000 of them are in the osv database I'm most likely that's because they're they don't put Cve's which don't apply to debion because it's a different version They will put them in security tracker Don't debion org but not in osv The second problem is with these ecosystems that the same problem is going to be registered in different ecosystems so so we have the The materialist Cve that I showed earlier has three different numbers in three different ecosystems on on osv And then each ecosystem has their own package identification scheme If you filter on package name it more or less matches But sometimes the package name can just be different like live curl in one ecosystem in curling another So it's not ideal It may be in practice is not so bad, but I have not really evaluated it so you need to do Cve tracking and Built roots and yokto have the tooling for that It's not perfect, but it works You do need to add some process on top of that to actually use it and This could become better if we could use osv But yeah, the tooling is not there yet, and it would require some effort to get that tooling to work And I have time for questions What's the state was kernel vulnerabilities? As far as I know the Linux kernel considers every bucket potential security issue But then Cve's are only filed by downstream Projects as far as I know so correct Anybody can Well, not anybody but a large number of people are able to File Cve's for the kernel and so you do have a lot of Cve's for the kernel But it doesn't mean that's something which is not mentioned in Cve Is not a vulnerability so yes, you have this thing that's maybe the Cve tracking of the kernel is not that useful Thank you for the talk and have you any Experiences or advices how often? The devices should be updated in the field specially in embedded fields. They are far outside in the Will dress used and then it's often hard to update in the field It's something that you need to evaluate. So if you If you look at the Cve's and you start evaluating them then actually In practice, it's rarely really applicable. I mean very very often what you have is that and Vulnerability could be used by an attacker but not on its own you also always need to stack several vulnerabilities to reach anywhere and so In in the sense that it could be used somehow it needs to be fixed eventually, but there's no It's not that urgent And also it depends on how Exposed your product is like an home gateway router is much more exposed than than a smart lamp Because the smart lamp is typically after behind nuts and stuff anyway So you really have to evaluate On the case-by-case basis Okay, thanks. Hi. Um, is there a way to match the osv database with the Cpe database or the Cve database so that you can kind of Cross-reference them and get to get to commit anyway for a seat for a Cve Sometimes so in the In this case This one yeah, you see already. It's the Cve number. So that's an easy match this one There is an aliases field in the database and it mentions the Cve number in the alias field So that's also easy. This one just mentions the Cve. Well, actually it's a it's an bunch of Cve's which are in a single security updates. And so The Debian only puts the security updates in there so there can be multiple vulnerabilities fixed in a single security updates and So that is not mentioned in aliases, but it's just mentioned in a text fix the Cve blah and blah and blah so that one is a bit more difficult to find but OSv has a really good search function. So if you search for that string, it will actually find it in that case Possibly there were others as well with the same Cve and I didn't find them because I just used that search function, but I'm not sure if how how useful it would be to do that because okay, you could cross-reference each Cve to the OSv database, but then if it's not in there You still don't know much. I mean could be something that is not applicable at all. So Maybe use a microphone After microphone here. I've also question. Okay in a talk earlier this week I've heard that the NIST server will be down by September. Is there a valuable solution for Yachto then? I Wasn't aware that the NIST server was going down Apparently they are changing the format. Right. So we are well aware and we already fixed that by defaulting to the new format So it will work as long as you have this Supported Yachto branch. It's new information for me. So I will use it in built routes. Okay If there aren't any other questions, thank you for the talk