In this technology and the arts course, you'll learn a little something about all the artistic and technical components that go into the creation of video games. We'll be exploring the history of video games, video game engines, traditional art principles, fundamentals of visual and audio design, and the elements of visual storytelling. We'll start by analyzing the artistic design process and creating original artwork based on your personal interests. You'll also create original sounds, 2D and 3D models, and use elements of AI machine learning to create new art. Each unit will have both technical and creative challenges, mixing synchronous and asynchronous activities. You will be encouraged to explore your personal interests and create something you are passionate about by identifying real-world issues that need solving, creating solutions to problems through the design process, and ultimately building the type of virtual world that you want to see for yourself and your future. This course is for anyone who wants to know more about what goes into creating video games, virtual art, and how to create art in 3D spaces.


Let me turn now to the internal judicial practice of the court and explain what happens behind the scenes that is after the parties have submitted to the court their final submissions and the court begins its deliberation up to the judgment. From that moment onwards, when final submissions have been made after the end of the oral pleadings, what happens within the court and how are judgments drafted? The internal judicial practice of the court is detailed in a resolution the court adopted in 1976 and which is posted on its website. It's called Resolution Concerning the Internal Judicial Practice of the Court. And I have served as First Secretary of the Court in a previous professional life. Let me set out the essential elements about how things are done behind the scenes. And on that basis, let me give you also some reading tips when you read ICJ cases. One month before the beginning of the public hearings, a summary of the arguments of the parties presented in their respective written pleadings is distributed to the judges of the court. The summary of the arguments of the parties is an internal document prepared by the registry. It is already a first digestion of the case presenting the issues in the logical order. But of course, because all along the way the judges and the judges at dark receive the written submissions of the parties, they do not wait for the summary of arguments prepared by the registry to work on the case. A second document is prepared by the registry. It is called In French de qualité and it summarizes the procedural history of the case and will constitute the first part of the judgment of the court. It is in that part that you'll find reproduced the various submissions of the parties presented at the end of their respective written pleadings and also the final submissions read out in court at the end of the public hearings by the agent of each party. And by comparing what each party exactly asks from the court at the end of each round of written and oral pleadings, you can actually see if and to what extent the dispute has evolved throughout the proceedings, if the proceedings brought the parties closer together and resulted in some claims being dropped, etc. The dispute that the court has to adjudicate upon is the dispute as it is reflected in the final submissions of the parties, not the dispute as it stood at the very beginning of the proceedings. And very often there is a difference between the two, which proves again that the sheer presence of the court has an effect on the scope of the dispute and that the virtue of judicial proceeding is to bring parties closer together and reduce the dispute to its essentials. Because the court's judicial function is to settle the dispute or rather what remains of the dispute, it must only answer the final submissions of the parties. A third document is prepared by the registry under the supervision of the presidents of the court. It is called the list of issues. The list of issues is a list of questions logically articulated with references to the relevant parts of the written and oral pleadings of the parties. The list of issues is approved by the full court during a short deliberation which is held just after the end of the second round of public hearings. It is then indeed that it can be finally adjusted in light of the final submissions presented by each party. After the list of issues is adopted, each judge sitting in the judge in the case is called to write within a certain period of time a note and present his or her views on the various issues raised by the dispute. The judges' notes are confidential and the judges are free to follow the structure of the list of issues or not to answer all issues or not. The notes are translated and distributed within the court at a certain date. If a judge has not yet finalized its notes, the notes of the other judges are not handed over to that judge in order not to influence his or her views. A few weeks after all judges' notes have been distributed, the court meets and begins its substantial deliberation. It is called Article 5 deliberation because it is envisaged under Article 5 of the resolution concerning the internal judicial practice of the court. The deliberation is held behind closed doors of the deliberation chamber and it is of course confidential with only a few members of the registry and interpreters present. Each judge is called to present his or her views orally and judges speak in the inverse order of seniority starting with Judge Adark, then the most recently elected judges and ending with the president. The deliberation may take several days or weeks depending on the complexity of the case. The president concludes the debate and the judges are free to react, conduct the debate and the judges are free to react to each other's views and raise questions. At the end of the deliberation, the president wraps up the debate. It is indeed at that moment that the actual decision of the court is taken. It is at that moment of the deliberation, in light of the views expressed by each judge, that one knows where the majority of the court lies, who has won and who has lost and on which issues. After the president has summed up the position of the court that is made clear in which direction the judgment would go, a drafting committee is elected. The drafting committee is usually made of three or four judges and they must of course reflect the views of the majority. The president is ex-officio, member of the drafting committee, if he or she is part of the majority and then two or three other judges are elected. The drafting committee is assisted by the registry and the judges by their respective clerks. After having met several times, the drafting committee produces a preliminary draft judgment in both French and English, which is then circulated to the other judges. And those other judges have a few weeks to submit written amendments, on substance or on form, and then the drafting committee meets again, considers those amendments, adopts some, reject others and issues another draft judgment. It is the draft for what is called the first reading. The first reading of the draft judgment takes place in the deliberation chamber, with all judges sitting in the case present, and the draft is read out by legal officers from the registry, paragraph by paragraph in both languages, French and English. After each paragraph, any judge is free to express his or her views to suggest amendments, a better way to phrase the reasoning, etc. The first reading is not supposed to be a second deliberation, but sometimes very substantial exchanges take place again. And it is at the end of the first reading that judges have to announce whether they intend to deliver a separate or a descending opinion. After the first reading, which can take days, and after having also received the draft separate or descending opinions, the drafting committee meets again and finalizes a draft for what is called the second reading. During the second reading, only the paragraphs that have changed in the meantime are read out and discussed. And at the end of the second reading, judges are each called in turn to vote on the operative part of the judgment. Judges may vote in favor or against, but they may not abstain. The vote is recorded and made public in the judgment, under each subparagraph of the operative part. And once the judges have voted, that's it. The judgment becomes resiudicata for them and for the court. It is then up to the registry to finalize the text of the judgment, to collect the judges' opinions, and to prepare copies that will be distributed to the parties at the end of the public reading. The public reading takes place in the Great Hall of Justice at the Peace Palace a few days or weeks after the end of the second reading. The internal procedure I just described is applicable in cases of judgments, including judgments on preliminary objections, and in cases of advisory opinions. It is a long and detailed procedure, and it is of course shortened when the court has to order provisional measures. In such a case, there is only one deliberation and one reading of the draft is prepared by the registry, and there is no drafting committee of judges. The procedure is long and detailed. It takes place in both languages, but it is also extremely deliberative and rational. A judgment of the court is the result of a real judicial deliberative process, with great minds exchanging their views and many pairs of eyes going time and time again over the same draft and the same questions. It is also important to remember that any decision by the ICJ is the product of a collective process in which no one single person has the upper hand, the rationality, the quality of the judgments, of the reasoning that you find in the court's decision stem from this lengthy, deliberative and collective process. However, now that you know how judgments of the ICJ are made, you can also better understand what a judicial process is about. It is about letting the disputing parties present their arguments and evidence on an equal footing, then take a decision about the dispute, and then, after the substantive decision is taken, put in writing the best available reasons in favor of the decision that has been taken. Therefore, I strongly suggest that when you read a decision of the court, or of any court, or tribunal, be it domestic or international, that you start by looking usually at the beginning of the decision, what is respectively claimed by the parties, and then you turn immediately to the very end of the operative part. That is the actual decision taken by the court. And only after you turn to everything that is between, that is the judicial reasoning of the court. The decisions are drafted in such a way as to make the conclusion, the decision, inescapable, as if, with such reasoning, only one conclusion could be reached. But of course, the reasoning itself is a choice, a choice made on the basis of the decision which has already been taken. By saying that I'm not suggesting that judgments are political decisions wrapped up in legal arguments, and that the judge would be always free to come up with any sort of outcome, not at all. Because the judge is compelled to give legally articulated reasons for its choices, the legal language which serves to justify its choices will considerably constrain and limit those collective choices and direct the judge to a certain outcome. But choices will nevertheless be made. And in light of this, let me suggest that the task of a counsel is to try to convince the judge that some choices cannot be reasonably made under the law, that the law leads to a certain result that are more easily justifiable under the law, or at least that the outcome favorable to the counsel's client can be perfectly and convincingly justified under the law. And is also well-grounded, in fact, facts, being of paramount importance, if not central in any judicial settlement.


In this presentation, we will take a look at multiple choice questions related to partnerships. First question, a partnership designed to protect innocent partners from negligence claims created from actions of a Nether partner is A. A partnership B. Limited partnership C. S. Corporation D. Limited liability partnership and E. Unlimited liability company. So we'll go through this again, see if we can eliminate some options with the process of elimination. Question, a partnership designed to protect innocent partners from negligence claims created from actions of a Nether partner is A. A partnership. The partnership is going to be the general liability and it's probably not going to be the one designed to protect it more. We're going to talk about one of these kind of hybrid type of options to protect partners. So it's not going to be the normal partnership. A limited partnership. We might think that as an option, but that could protect typically an individual partner if we had a limited partnership where one individual was a capital investment typically. But the general partners wouldn't have that same type of protection possibly. So I'll keep that for now. C says an S corporation and that's not a partnership. It's similar in that it's a flow through entity, but not a partnership. So I'm going to say that's not the one and D says limited liability partnership. And that sounds pretty good because that's going to be another one of those hybrids. So it looks like it's between B and D at the moment. And then E says unlimited liability company, which is kind of a funny term because like you don't want an unlimited liability company. You want a limited liability company. So it would be kind of counter productive to make an unlimited liability company. So that seems not correct. So we're going to go between B and D question one more time or once again. A partnership designed to protect innocent partners from negligence claims created from actions of another partner is either B or D either limited partnership or limited liability partnership. And of those two, I think that D is going to be the more proper term because it's going to give more protection to all the partners from negligence of other partners. Whereas a limited partnership will only do so for the limited partner, the one that doesn't participate in the partnership and therefore should not have or the justification for limited partners. They don't have a liability because they're not really in the decision making process. They're really more of an investor. Next question. A partnership where partners have unlimited liability is called a limited partnership, b limited liability partnership, c general partnership, d C corporation, e limited liability company. So let's go through this again, see if we can go through the process of elimination. A partnership where partners have unlimited liability is called a a limited partner. A limited partnership is going to have not unlimited for at least an individual. So unlimited liability of course is bad. Typically that means that your your personal resources are are subject to possible a lawsuit or something like that happening. So a limited partnership is going to limit that in some ways, at least for some partners, the ones that are not involved directly in the partnership. So it's probably not limited partnership. The B says limited liability partnership. And again, that's like the hybrid between a partnership and a corporation. And that's the point of a limited liability partnership is to have more liability protection. That's why you do it. So that wouldn't be unlimited either. C says general partnership. Probably the answer because a normal partnership is a general partnership. And that's the one where you got the liability issue. So that probably is the one. D says a corporation and there's no unlimited liability in a corporation. That's the point of incorporating and it's not a partnership. So that doesn't sound right. And then E says limited liability company. And once again, that's a hybrid very similar to be up here that's trying to have the best of both worlds, the point being to limit liability and not have unlimited liability. So that's not going to be it. We'll be left with C then, question and answer. A partnership where partners have unlimited liability is called C general partnership.


Great. Welcome to All Things in Toto. I am Santiago Torres. I work at Purdue University. I'm an assistant professor and I do research on software supply chain security. That is, I care about how software is made securely and I care about how software is consumed securely. And here's my colleague, Marcella. Hi. I'm Marcella Malara. I'm a research scientist at Intel Labs. My current research focuses mostly on software supply chain security, but more generally, distributed systems and security. So this is right up my alley as well. Should we get started? So we want to sort of set the stage in a common language to talk about the software supply chain, software supply chain security. So we're going to start with some basics. The software supply chain, the way we see it, the way in Toto sees it, is a collection of all the systems, devices, organizations, actors, individuals that are involved in producing a software product. So a supply chain attack is essentially a compromise of any one of those elements of the software supply chain, any one of those components, and in particular, when they take advantage of a weakness. The common goal, of course, then being some sort of alteration or modification, mostly malicious to the final product. And we always like to point out this very kind of impressive statistic, right? Over the course of three years between 2019 and 2022, Sonatype essentially identified the rate of growth of software supply chain attacks. And over this three-year span, a 742% growth is astronomical. So this really is a very crucial problem. And so we can point out a few different examples. Some of you may be familiar with these. SolarWinds is probably the one that most folks here have at least heard of, right? The SolarWinds hack to be very specific, right? SolarWinds being a company that, even though they had open sort of software and a lot of these security measures in place already, right? They still had a loophole or weakness in their supply chain that was then taken advantage of by attackers. So to address all of these issues, right, there's kind of a growing ecosystem around this problem. And we bucket the solutions into three main areas. Evidence gathering, information discovery, and policy or validation. And we've highlighted a few of the CNCF and open SSF projects that are sort of making headway in the space. You're probably familiar with at least some of these. In Toto in particular has also seen a lot of integrations and adoptions in recent years. So these are the projects specifically in the CNCF. Then in open SSF, there are several standards that are emerging here. And this is sort of more broadly an ecosystem. And these final ones that we're popping up are really sort of in Toto friends, as we call them, right? These are the adopters of the in Toto standards and tooling so far. And then finally, most recently, I think this has been within the last year, right? NPM and GitHub, for example, we like to highlight especially because they have sort of really adopted and integrated in Toto at a much larger scale, right? NPM being the largest package management service and GitHub being one of the largest CICD services. So working together has really sort of expanded the reach of in Toto really. So I'm going to hand it off to Santiago now. So by now you may be convinced that in Toto is involved in all of these different initiatives that you may recognize. And that in Toto is probably a fundamental part of this software supply chain security problem. But you may be asking yourself, what is this in Toto thing anyway? And well, in Toto really is a way to talk about how a software product is made and to see essentially every single step that was carried out. The way that in Toto works is that it allows you to wrap all of these different technologies that you're familiar with. If you're familiar with Salsa, well, you can use in Toto to communicate Salsa predicates. In the slide that you're looking at right now, it looks a little bit daunting. But really what it really means is in Toto allows you to bind information from software supply chain predicates. Like in the bottom we have a subject, for example, an S-bomb. Well, a subject, for example, a container and a predicate, for example, an S-bomb. We're saying I am attaching this S-bomb to this particular artifact in the software supply chain so that you know that this S-bomb is associated with this particular container. It also allows you to do other things such as authenticate that particular attachment so that you know that the person who is attaching that S-bomb to that container is the person that you trust to attach that S-bomb to that container. Well, this allows us to do sort of like a very simple graph construction. We're building the supply chain through its evidence. So in this case, for example, we are able to allow all of the people that are producing a piece of software, in this case, say a Debian package, to produce attestations as things are moving forward. And eventually, using a policy language, whatever you're more familiar with or more inclined to use, OPAC, you can look at all of those attestations and say, well, is my package packaged by the Packager? Is my software written by the developer? Is the build system that I'm using, the one that should be building this binary to begin with, is my Travis CI deployment actually running the tests on the same software that was put in my package or is it running tests on something else? And through this, then, we're able to get a very sort of highly granular, very visible understanding of how the software is made. Now, all of these little pieces of evidence that we were looking at just earlier, these are called attestations and they are essentially little atoms of how the software supply chain is connected together. We also call these predicates. These predicates, again, allow us to talk about different properties of a subject and the subject, for example, is any piece of software or intermediate piece of software in our software supply chain. So, I don't know if you noticed, but this really does look like a grammar and this is not a coincidence. We're trying to answer and ask questions about the software supply chain so that we can better determine how much we trust the piece of software. Questions that you can ask yourself is things such as how solar winds solve the solar burst compromise.  I hope they don't sue me, but this really lets us get some visibility in how really they took a look at this problem, the largest compromise in the history of the United States and how do they think they will solve it using in total. Essentially, what they're doing is they're using two pipelines. One of them is in a completely isolated environment with a completely different stack that is rebuilding the software. The claim here is that if these attestations and the other attestations that are coming from the production pipelines agree on the result of the binary, then the likelihood of a backdoor being in the build system is very low. This means that the hackers should have broken not only into the production environment, but in some other siloed, isolated verification pipeline that they put in a different location, such as the case of Datadog, that they also build somewhat of a more linear pipeline to verify how software traverses their supply chain. At the very left-hand side, they hand out a hardware security module to every developer and they use it to automatically sign every single release that they are producing. When that release is pushed into the CICD system, then the CICD system also produces a bunch of different attestations. You can think of this as salsa attestations, and I don't remember if these are actually salsa, but you can then bind these two things together. The developer actually produced the software that is being built right now, or is it building something else? Finally, when you get to download the agent that's running in your infrastructure, we'll download these two attestations and then it will do a couple of checks. The first one is, did I download the thing that's a subject in the latest attestation, and the other thing that's actually very interesting? Can I go all the way back to the original source code, the Python files that I found, and match them to the developers that are building this software in the New York Times building in the Datadog office using a hardware token? So that way they know that no single line of code was introduced, nothing was really modified by the CI. The CI is really just running the tests and packaging the software. Another example that I wanted to highlight is, and it's something that's really exciting to me, is how can you combine six-door salsa and in-toto to bind GitHub Actions and NPM? The way that they do it is really, on their workflow, they have their NPM GitHub Action authenticate the runner and then spit out a salsa attestation that's being signed using six-door. To answer the question, well, is this GitHub Action, the one that produced my piece of software, or did somebody try to replace the NPM package on the registry by building it themselves in a different computer? These are not all the questions that you can answer or ask within totos. You can ask very simple questions like, who did what? Who was the developer that did this particular change? Or who changed which particular container? Which tools were they using? Where are they running these tools? And is this what they should be doing to begin with? Is their CI configured in the proper sort of way? You may have also noticed other tools that can produce attestations today. We have a very rich integration environment. Trivi, for example, can spit out both at Nesbom and I think of a vulnerability scan attestation that then you can attach and ask yourselves, did anybody run a vulnerability scan in this container before I admitted it into the cloud? When did they run it and what was the result of it? Salsa is probably something that you're very familiar with and you can answer the question, how was this particular software product built? A little bit more loosely, can you ask yourself, did somebody run the tests? Did they even pass? Or was there a runtime trace? Essentially showing me evidence of this container running in an isolated environment when it was building this piece of software. And really anything that you could collect throughout the software supply chain, the idea is that we want to push that forward and verify it. Take everything from the left-hand side to the right-hand side to verify properties of the software supply chain in both a cryptographically strong, but also in an automatic operationalized fashion. Actually something I'm very excited is Intel donated some code to the Intel framework that allows us to answer even more complicated questions that I have just now, and Marshal is going to show us. So this is really an overview of the demo that I'm about to show you. So the idea here is when Mary the maintainer submits a pull request to a Git repo, right, this is the CSED pipeline, and specifically if you're using GitHub, the GitHub Actions workflow will trigger the build, generate the build output, write your artifact or container, whatever it is that you're building, and in addition also the metadata that is required to generate the intuitive attestations. Thanks to work that I've done and with the intuitive community together, as well as prior work right from other communities and other community members, we then sort of again through the CSED workflow can actually sign and upload these attestations to the six store transparency log and verify the inclusion proofs, get those artifacts, get the attestations on Camila, the customer side, and verify that the software artifact is actually compliant with our expectations, with our policies using the attestations that were generated during the build and signed by Mary's organization. So as Santiago was alluding to, part of what we want to spotlight in this demo is the Sky Predicate or the supply chain attribute integrity predicate, which essentially seeks to bind explicit attributes about any aspect of the software supply chain to evidence of these attributes. And there's a few more fields in this predicate. I'm not going to walk through the JSON today, but hopefully get the idea that we are able to not only generate data, but start sort of deriving meaning from this data for verification purposes. So the sort of questions we seek to answer in this demo are including, was the build tampered with, right? Was the legitimate version of the source repo used? These are questions that Salsa Providence can answer. Did the build produce an SBOM? Did the build produce Salsa Providence? These are the types of questions that the Sky Predicate can then, in addition, answer. So for this, I will... You can see my screen, yes. Break out of here. Do we have a drum roll? Yeah. There isn't anything actually live running right now. This build takes about 30 minutes, so I'm not going to have everyone sit and wait for that. But essentially, so this is a fork from a team project that my team maintains at Intel, private data objects. We build several containers for a distributed system type application and smart contract type application. And what I really want to showcase here is the SBOM generation for one of our containers, the client container in this case. We generate the various information that we need for the Salsa Providence in addition to a few extra sort of logs and whatnot. So after that, right, the workflow, right, here's our builds. Here's the stock Salsa Providence GitHub Generator workflow that I was able to just plug into my workflow and generate Salsa Providence with. And kind of just as part of this tool, we are able to generate six store signed in total attestations that have the Salsa Providence predicate in them. And so if we go over here, yes, you can sort of see this is the actual recorlog that was generated for the spilled. And here's a Salsa Providence attestation that you can verify, you can check against to obtain the signature from. And so then similarly, we built a similar workflow for Sky. So these are available at our Sky Demos and Todor repo. And here our idea is to generate what we call attribute assertions and what these are really just sort of individual mappings between attributes and evidence files. And so as you can see here, we're generating an assertion saying that, yes, we have Salsa Providence, generating an assertion saying, yes, we generated an S-bomb, and our workflow will sign off on this again and upload it to six store, much in the same way that the Salsa GitHub Generator does that. So again, we can walk over here to our recorlog, find, for example, the inclusion proof for our Sky attestation. And if I pop this open, we can see here this is our client container commit over here. And here we have the has S-bomb, has Salsa, and I'm also asserting that, well, this container was not built hermetically. I'm not going to go into what that means, but we can talk about that later. So essentially, what's kind of important to point out here is that our evidence is the JSON blob that we generated, or JSON blob. Yes, our JSON file that we generated, and similarly for our Salsa assertion, we're saying, yep, here's the Providence that we generated. So if we go back to our workflow summary, we'll see, hey, here's all the artifacts, including our SPDX file, our signed Sky attestation, and so forth. So that's on the generation side. On the verification side, let me pop this back for a second. Right, there is steps five and six that need to happen. I'm just going to point out that for the sake of brevity and making sure that the demo goes smoothly, I will not be showing steps five and six today, but these are kind of important steps to do this pre-verification essentially on the authenticity and integrity of the attestations coming from six store against what it is that you get from your GitHub workflow. So I'm going to be showing step seven next. So I open up my shell, and I wish I had... Is this font size readable, or should we make it a little bigger? It's good? Okay. Thanks, yeah. So if we look at our attestations, we have our build attestation and evidence collection attestation. These are essentially the Salsa and Sky attestations. This is how the Intodo attestation verifier consumes them, so I need to rename the files. And then similarly, if we look at our evidence files, one of the evidence files for one of our Sky assertions is that same Salsa attestation, right? So I'm going to just run the verifier for a particular layout. So the layout is essentially the Intodo policy definition. And we can go over that in a moment. But essentially, this tool performs a whole host of verifications, right? We are checking the signatures on our attestations. We are evaluating policy rules on each predicate in the attestation once we verify the signature, and essentially just making sure that every single rule applies, right? In this case, yay, verification was successful. And if I... the layout... Again, I'm not going to go through all of this, but over here, right, we have our functionaries. These are the signers. We have all of this key information. And so here, we have the build step that generated the Salsa provenance. And then down here, we have the evidence collection, which generated the assertions about our build step, right? So you might see our rules down here say, you know, we want to make sure that our attestation says that we had a Salsa provenance or Sbom generated. So then we run our Sky Generator or SkyGen check evidence tool to essentially check the evidence in one attestation against that particular actual evidence file. This is a slightly shorter check. The idea is to eventually integrate this into the attestation verifier as part of that flow. But what we're doing here is really just... It's essentially checking our Sky in total attestation against this particular policy and against the Salsa provenance file, right? In this case, we just want to make sure that, yes, our Sky predicate has the right attributes that are being asserted and a couple of sort of additional fields and attributes instead of our Salsa provenance, which again is our evidence here. So that concludes the demo. Hopefully that demonstrates kind of clearly what is going on here. And, yeah, handing it back to you. Okay, so with this demo, you saw really the power of Intoto. You can check not only that Salsa exists, but that Salsa is up until certain level and that there's evidence to support that the Salsa level that you actually recorded matches the Salsa level that you expected. Now, Intoto is a community project and we're not just doing a marketing pitch, but we want to also talk about how you can participate, become part of a community and pretty much help us grow this project that really to secure the software supply chain we need to cover the whole supply chain. So Intoto is really a specification with a series of implementations and a process to enhance the Intoto specification. These are called Intoto enhancements. What I mean with enhancement is if you have an idea of a way to improve Intoto, you can talk to us and we can encode this. This is heavily inspired by pretty much anything that ends with EP in the open source world. The enhancements then are floated back into an implementation and we try to keep this ecosystem steadily growing to both sandbox certain experimental features but also to support pretty much people that have been using Intoto for, I don't know, four years already. The major implementations that we have are Python, which is usually our stable implementation. This is the one that we try to pretty much fix security issues but not add any sort of weird new features.  It's pretty much bleeding edge. It's the one that we use to test new features. We also have implementations in Java. This is mostly used for the Jenkins plugin. If you're using Jenkins, you can install an Intoto provenance generator. And the Rust implementation, which is used by another project called RebuilderD, which is heavily connected with the reproducible builds project. A way to verify artifact reproducibility is actually using Intoto to verify attestations about multiple builds on the same piece of software. ITS, again, are the way that we grow the community or grow the feature set of Intoto. We're moving really fast. As a matter of fact, this slide is outdated. ITS 9, 6, and 7, I think, are accepted. We have 10 and 11 now that are the ones that you saw in the Sky demo. If you have any idea, really, reaching out to the ITS maintainers, one of those is the best way to get the conversation going. When are you here at the station? Even if it's in the south side of the station format, they're probably talking about this document. This is where attestations were referred to find for Intoto, and that's how they inspired the wrapper around Salsa. Intoto is a common language. Again, what we're trying to do is accommodate all of the communities, especially CNCF project, so that they can talk about the software supply chain or a particular software of the software supply chain and fit it with a bigger picture of software supply chain security. Yeah. There's a lot of attestations. It's still growing. If you have an idea of an attestation, for example, if you have a tool that you think could produce a piece of evidence that would help us assert new information about the software supply chain, well, reach out to us. We're really, really excited to work with new communities and find things out. We're both scientists, so when somebody comes with something we didn't think about, we really laser focus on that, and we really love to hear from these perspectives. A lot of the predicates were actually not built in-house, but rather some tool was generating something that's useful for us to make a more secure software supply chain, so we brought them into the conversation and then added support in our implementations or directed people to use that predicate as well. Something that does happen is that a lot of these attestations can also help to define a common language between all of the tools. We have a lot of different vulnerability scanners. If we are able to determine a predicate that accommodates all different vulnerability scanners, then we are better able to write tooling to support the treaty and SIFT and really anything out there. To define your attestation formats, you need to reach out to the attestation maintainers. You can pretty much do what you saw on the slide before, which is open and a pull request. Have a couple of comments. We have multiple stakeholders looking at this particular subset of the internal community to help accommodate and grow the predicate offering and also define best practices on how to use them. If you want to use, say, Sky, we have a whole Sky demo repo that can help you verify things like, oh, if I wanted to use Sky to verify a secure boot on a server, there's already a sketch of something you could start playing with. I want to verify Salsa level using a runtime phrase or a Skyatt station, then there's also some code there that can help you visualize how it works. Well, to wrap up, and I think we are... Yeah, we probably want some time for questions. We want to build more expressive policies. Ike 10 and 11 is what you saw on the demo. And what we're trying to finally close out is the loop of how we produce all of this evidence from all of these tools, all of the CNCF projects and open SSF projects collected using all of the tools and then verifying them at the time of deployment or pretty much just verifying at whatever time is possible. The internal community is pretty much a thriving community of people that are suggesting new heights, people that are building tools, people that are building demos, people that are maintaining the different implementations. Do reach out to us. We will definitely find a home for the type of work that you want to do in the community. There's really a lot to do in order to accommodate this very expansive goal. We have an internal community meeting at the first Friday of every month. So last Friday was the November one, but the December one should be in a couple of weeks. We're also in the CNCF Slack. We are also in IRC. It's not bridged, but if you want to do a contribution and hosting the bridge, that would be great. A mailing list and also, of course, the GitHub organization for you to reach out to. We also participate in Google Summer of Code. So keep an eye on that. We usually have a lot of ways to onboard up-and-coming students into the organization. This started as an academic project, so a lot of the mentoring will be done by both Purdue and NYU and the New Year's Institute of Technology. And I think that's it. We do have time for questions, right? We have about five minutes. So yeah, thank you. There has been, and that's a great question. So I'll repeat it for the sake of Mike. So we show the happy path, right? You collect all of this, you verify it, it passes the policy, everybody's happy. But has anybody tried to look into a way to subvert this sort of attestation process so as to introduce a supply chain vulnerability, though in total it's in place. So yes, we have been looking at it. There's a formal security analysis. We've published the paper back in 2019. But more importantly, we had a third-party security audit that was concluded earlier this year. Am I right? Earlier this year, I think like around March or so. I can't believe it took over November. So yes, they also found ways to do it, and really it boils down to implementation aspects. Like there are some places in which you can introduce ways for the attester or the attestation code to attest for a lie. But we have been doing a lot of work to isolate these components, right? The thing that's actually carrying out the software supply chain action, and the thing that's observing and rubber stamping the particular attestation. Yeah, I think we have time for a few more questions. Yeah, sure. So one of the things I noticed in your demo was that it seemed like it would help some of these assertions or attestations would help with S-bomb discovery. They had kind of pointers to download locations of S-bombs. In addition, I recently was looking at the security and site CMO specification, which also has a way to discover where to download S-bombs. And I know that S-bomb discovery in general was like a pretty big problem. Would you see those two specifications maybe working together, or how would that, Very good question. Thank you. I think they would probably be complementary. I also think that in Sky could probably express some of that other specification. But in general, that is just one of the applications. So Sky is very specifically designed to be as general as possible. So this just seemed like one of the sort of most straightforward applications to aid with, like you're saying, S-bomb discovery, attestation discovery in general. And I don't know if anyone here is familiar with Guac, for example, but we're sort of trying to show here if we were querying any kind of attestation database or attestation log, where we are retrieving some of these attestations or signatures that we can actually generate in attestation about what this log is also telling us. So in addition to discovery, we're trying to also sort of add an extra layer of integrity to that. So I think it went beyond your question. But I think we have time for one more. And a quick shout out to Archivista as well, which is another project to help with discovery of attestations. It's really like optimized for asking anything about a piece of software and then telling you everything it knows. I think there's a booth on... Sorry. The number of project is Archivista. Yeah. I think they have a booth, the company's testify sec, in the pavilion. We have time for one last question. I think it needs to be quick. Well, I don't know if this is a quick question, but I noticed that one of the steps that we skipped was step five of getting the actual attestations for the resource. And I'm curious what ecosystems have support for automating that, because I know OCI has recently added that, and NPM I think has added some of that. But are there other ecosystems that are integrating that right now? Yes. So the ecosystem that we've been exploring has been mostly the six store recore ecosystem. Unfortunately, they don't have strong support for actual attestation storage, right? They're primarily for signatures. And so there's some quirks with the APIs and those kinds of challenges that we ran into. But that's more sort of on the engineering. I think that's more an engineering problem than an ecosystem problem, per se. But I think, again, that's where a tool like Archivista could come in, which is tailored specifically towards storing intuitive attestations and SBOM and those kinds of metadata. And so I think in lockstep with some of these other ecosystems, they could really sort of work there and integrate. Thank you. Thank you, everybody. Thank you.


Good morning, ladies and gentlemen. Thank you for joining us for this information session on COVID-19 or coronavirus. As you may have heard in the news, this situation is serious. We need to ensure the safety of the detainees, your safety, and that of our visitors. By now you all know COVID-19, its symptoms and hygiene measures you can take individually to prevent it. If you have any questions, our health colleagues are organizing information sessions. It is important that we all work together and coordinate our efforts with the local authorities as well as the Ministry of Health. Detention facilities are at a higher risk of quickly spreading the virus as we all work or live closely together. To keep you and detainees safe, we will need to make some changes to our daily work. It is worth remembering that the only way COVID-19 can enter our place of detention is through a person, detainee, staff, or visitor. Doctor, could you please remind us of the basic recommendations? Yes, sir. Ladies and gentlemen, firstly everyone including staff will be screened for symptoms every time they enter our facility. If you or someone you live with show symptoms of COVID-19, you should not come to work and you should inform your manager. If a case is found among staff or detainees, we will work with the health authorities to see who else might be at risk and may need to be isolated. For staff, this may need having to stay off work for a period of time. Moreover, please respect the rules of hand washing, covering your mouth and nose with your flexed elbow or a tissue when you cough or sneeze. Staff who may work in contact with detainees infected with COVID-19 will be provided with proper safety equipment to protect themselves. When it comes to detainees, we may need to isolate those presenting symptoms to make sure the virus does not spread further according to agreed plans and standard operating procedures. Detainees will be told to inform a member of staff if they have a fever, cough, breathing difficulties, sore throat or runny nose. If you are told by a detainee that he has COVID-19 symptoms, you should keep the detainee away from others and inform health staff immediately. During this time, please pay particular attention to vulnerable groups, including elderly detainees and those detainees who are already being treated for other illnesses. Their good health is our good health. Thanks doctor, we have drafted a contingency plan to see how daily operations have to be adapted to prevent the spread and respond to a possible outbreak. In particular, we will need to plan our staffing arrangements carefully, as some staff may become sick and will not be able to come to work. We will also need to plan how we run the detention facility if there any suspected or confirmed cases appear. This includes the need to review the activities detainees take part in during the day. Some may need to be reduced or shortened for their protection. Moreover, regarding family and legal visits, physical contact between detainees and visitors may need to be stopped. If the risks increase, visits may need to be cancelled for a period. In that case, we need to replace visits with telephone or video calls. We will need to inform the detainees as well as visitors before they travel to the detention facility. Finally, we also have to organize the possibility for the families who usually deliver parcels to keep doing so with sufficient safety precautions. Regarding detainees, all new arrivals will be screened by the health care team. We will talk to judges, prosecutors and lawyers regarding the postponement of court appearances or trials to limit or even suspend them if the situation requires. It is crucial that we inform everyone concerned, people detained, their families, contractors, visitors and the local authorities and media. In the facility, we will also need to review our isolation procedures, access to showers, outdoor exercise, toilets, catering arrangements and the delivery and service of meals. We have to see with our budget and our head office if we can have enough funds to get more hygiene items.  If needed, we will prepare our own chlorine solution to disinfect our premises. Moreover, we need to make sure that hygienic and sanitation practices are properly done in all the areas, including in the yards. Part of this will be creating hygiene committees and making sure they are given proper training and supplies. Could I ask the maintenance team to immediately look at the ensuring and the separation of detainees, a proper ventilation and access to water and sanitation and improving this where needed. We also need to ensure that rubbish is collected and removed frequently from the facility and disposed of safely. In that regard, maintenance and technical teams need to be reinforced in coordination with the municipality and services providers. In case of needs, we will establish backup systems accordingly. Any question, ladies and gentlemen. Sir, what about the distance we need to put between us? There are cells where there are more people detained than the number of places. There are measures that we can take already. We have decided to stop large groups of detainees coming together in exercise areas, canteens, workshops and religious buildings while maintaining access to fresh air. We will also seek to minimize all non-essential movement within the facility. Moreover, arrangements for the release of detainees who have completed their sentence are also being discussed at national level in order to reduce overcrowding. Any other questions? What is the procedure to treat a detainee who is infected with COVID-19? A detainee who has COVID-19 symptoms or who tests positive for COVID-19 will be isolated or sent to hospital depending on the severity of their symptoms. It is important for COVID-19 patients in isolation that all their usual daily needs are met and that they are treated well. We all follow good hygiene measures. You do not have to fear catching COVID-19 from them. When in contact with those detainees, you should always wear protective gear. It is very important that you put these items on and off properly. You will receive training on this. If you are ever unsure, please ask health staff for guidance as using the protective gear wrongly can leave you at risk. Ladies and gentlemen, dear colleagues, let's not wait any longer to get ready. We must be prepared in advance to know exactly what to do. Let's work toward ensuring humane and dignified treatment for people detained here during this period. We will be holding regular information sharing sessions with detainees, between us and with visitors. It is very important to keep detainees informed to reduce the risk of misunderstandings and tensions. I thank you very much for your solidarity. Again, the better we manage this in our daily work and ensure respect for preventative measures, the more everyone will stay in good health. Again, the good health of detainees is our good health.


Welcome to the Endnotes, where I put all the fun facts I can't fit into the main videos. Today, an extra bit of information from my video about what is a recipe, and if you haven't seen that, click on the card. When I talked about ancient medicine in that video, I mentioned the basics of the theory of the humors, so here's a little bit more about those four humors. Let's start with blood. The Greeks called it haima, from which we get words such as hemorrhage, the bursting forth of blood, and hemoglobin, a component of blood. The Romans called it sanguis, one of the two main words for blood, this one for blood inside the body which gives us words such as sanguin, the temperament associated with this humor. The other word for blood, cruror, refers to blood from a wound coming from a root that meant raw flesh, and is related to such words as crude, cruel, pancreas, and raw. In case you're wondering, our English word blood comes from a root that means swell, gush, or spurt, lovely, and in turn from a deeper root meaning thrive, or bloom. Blood was associated with the spring and the element air of the four classical elements, earth, air, fire, and water. It was associated as well with the liver, makes sense, and was considered to have the qualities warm and moist, again makes sense. The next humor, yellow bile, was called by the Greeks, ketrini chole, the word chole giving us choleric, the temperament associated with yellow bile, and also distantly related to the word yellow. Bile we get from the Roman term billis. According to the humorists, yellow bile was associated with summer, fire, and the gallbladder, and was considered to have the qualities warm and dry. Excess of yellow bile could produce aggression and anger.  That first word, malena, by the way, comes from Greek mellas, meaning black, and also gives us the word melanin. Black bile was associated with autumn, earth, and the spleen, and was considered to have the qualities cold and dry. Black bile was thought to produce depression, or what was called melancholy. And finally, we have the phlegma in Greek, which was associated with winter, water, the brain, and lungs, and was considered cold and moist. Surprisingly, it produced the temperament phlegmatic, a word we still have with a sense of apathetic. By the way, phlegm comes from a Proto-Indo-European root that means burn, shining, or white, which perhaps oddly gives us the colour words black and blue, as well as the more obvious bleach and blonde. This etymology may seem at odds with the associations of cold and moist, but probably has more to do with the colour. So the ancient or medieval physician Slash Cook would have to keep in mind all these associations when preparing food. So for instance, a winter sauce would use hot and dry spices, such as mustard, ginger, pepper, cinnamon, and cloves, to keep one healthy in those cold months. But such hot, dry spices would be avoided in the summer. If a patient was reckoned to have an excess of a particular humour, foods with the opposite qualities would be prescribed. So the proper menu had to include the appropriate recipes, and the right food was just with the doctor ordered. As always, you can hear even more etymology and history, as well as interviews with a wide range of fascinating people on the Endless Knot podcast, available on all the major podcast platforms, as well as our other YouTube channel. Thanks for watching!