I want to introduce you to what we mean by security. Computer security, network security, give a few definitions, and then talk about some of the concepts that we use when we talk about securing computer systems. Hopefully we'll finish this today. We may get on to the next one, but just a light introduction to security. Some definitions. What other people think of, what is security? The first one comes from an organization called NIST, the National Institute of Standards and Technology in the US. They are a government organization that creates standards in the US, but they produce a lot of standards about how companies and people should use computer security. They say computer security is the protection afforded to automated information system in order to obtain the applicable objectives of preserving integrity, availability, and confidentiality of information system resources. So a long definition. What can we pick out there? Okay, so we want to protect some computer system, an automated information system, and protect it to attain some objectives. So we're going to see that we need to have some objectives. If I have a computer system, then from a security perspective, we'll have some objectives of what we want to achieve with that system and how do we want to keep it secure? And we'll arrive at talking about security policies in one of the later slides. And we want to preserve, for that computer system, preserve the integrity, availability, and confidentiality of information, or information system resources, not just information resources. Resources include, for example, the processing and the memory resources on the computer, network resources, as well as files, that information. So another definition before we look more depth at these parts. This is about, the first one is about computer security. So generally about securing computer systems. Computer systems include securing a standalone computer, like a laptop or a server or a mainframe or a TV. They may also include collections of computers, so a network of computers. But sometimes security of computer networks is treated separately than securing a computer. So there's a lot of overlap, but sometimes the techniques we use to secure my computer on its own may be slightly different from what I use to secure the communications between my computer and another computer across a network. Here's another definition of network and internet security. So communications across a network, how do we keep them secure? Well, the measures we use to deter, prevent, detect, and correct security violations that involve transmission of information.  It's about getting information from one point to another, transmitting information across a network. So if there are security violations, that is when we transfer information across the network, something goes wrong with respect to security, then we wanna look at, well, how do we stop such violations? And in some case, fix and detect them. So to deter violations, that is to make people not want to violate the security of my network, to prevent them, to make it impossible for someone to violate the security of my network. Detect is if someone does violate the security that I at least know that it happened. And correct is, okay, if something is violated in my network, then I can fix it. So we'll see that prevention and detection usually go together. These are just two definitions of computer security and network and internet security. The second one is from your course textbook. It's by William Stollings called Cryptography and Network Security. This is the fifth edition. There's a sixth edition, I think, just released. If you're gonna buy a textbook, buy this one.  But it is a good textbook that covers all the things that we cover in this course. So let's look at some of these things in more depth. So some of it may not make sense yet. In the definition of computer security, there was we wanna preserve integrity, availability and confidentiality. And those are three concepts that come up quite often talking about security. Confidentiality, integrity, availability, CIA. Not the organization but the combination of these three concepts. What confidentiality is keeping things secret, keeping information confidential. I think that's what many people think of when they think about computer and network security. You send a file to someone else. You don't want someone in the middle to intercept and read the contents of that file. You wanna keep it secret. You wanna keep it confidential. So that's a common thing that we need in computer systems to keep information confidential. Integrity is making sure that the information or the system is not modified in some way. An example, and we'll see some other examples later, but one common one is that we wanna send data to some destination even if we allow it to be seen by people. That is we don't care about confidentiality. I don't care if someone reads my message. I would still like it such that no one could modify the message along the way. So that I send a message to you, the message that you receive is identical to the one that I sent. That is about the integrity of the message, the integrity of the information. If I send a message to you, but someone malicious modifies that message along the way and you receive the modified message, that can be a security violation. So integrity is also important. The last one in this triangle is availability. And that often refers to the availability of a computer system or a computer network. The purpose of computer systems, computer networks is to provide some service to the users. A server, a web server is so that people can turn access the files on that web server, an email server so that they can send emails. A security violation of a computer system may be making that system unavailable for the normal users to use. So for example, Amazon has a web server. You go there to buy things. If someone violates the security of the Amazon web server such that you can no longer go there to buy things, that can be considered a security attack because the availability of the Amazon web server is no longer available. So we treat this as an important security issue, making sure the computer system is available. In the case of Amazon, if their web server is down for just a few seconds, then they're gonna lose a lot of money. So it can have a significant impact if our computer system is not available because of a security violation. You may have heard of denial of service attacks. And that's the main form of attack on availability. So we'd like usually to have confidentiality, integrity, availability. Maybe not always all three, but there are three common concepts that we see in computer systems. There are others, sometimes we distinguish between also we identify authenticity, making sure either the information or the people that we're communicating with are authentic. Someone sends your message. The source says it's from Steve. You want to be sure that it's from Steve, it's not from someone pretending to be me. That's about authenticity. Accountability is to make sure that we can contract and keep monitor of what things happen and that we can track things back to who caused some particular event. We can hold them accountable. So a computer system or a computer network, we usually want to focus on making sure the information is confidential. It maintains its integrity and we have availability of that system. We will not go too much into what happens when a computer system is compromised, but I think you can think of many examples, but how does a breach or a compromise of a computer system impact upon organizations? For example, SIT. We're an organization, what's our business? What's the business of SIT? Education, okay? So SIT makes money by educating people. So that's our business. What if there's some security attack on the SIT computer network such that something goes wrong on the computers, on the servers or some part of our network? Well, there can be different impacts on an organization, ranging from minor to catastrophic, very bad. So some examples, a common thing if there is a security violation is that the effectiveness of that organization is reduced. So the primary operation of SIT is education. We teach people. If, for example, someone does an attack on our network and they reboot this computer, like someone did in my lab yesterday, then it's going to stop me from teaching for two or three minutes. It's going to reduce my effectiveness in our operation of education. Well, not so bad. You may enjoy the break for a few minutes, but you can imagine if someone did an attack such that they deleted all the files on my laptop, then that's also going to reduce my effectiveness because I'm going to have to recreate all my lecture notes and get backups and so on. So security breaches can reduce how well an organization operates. Sometimes it's just an inconvenience. Sometimes we'll lose money because of that. So you can think that if someone logs or accesses SIT's network and manages to delete a lot of confidential information then recreating that and getting it from backups may cost us money. So we may lose money. There may be damage to real hardware, damage to assets. An example that happened one or two years ago, maybe even a little bit earlier than that, was an attack on some nuclear power plants in Iraq that was basically some form of virus was installed on the computers inside the nuclear power plants and the idea was that it would cause some of the machinery there to operate outside the normal specs that it will operate in an unexpected way such that the machinery would break down and that effectively damaged that, the assets that damaged hardware in that case. So it can not just mean to loss of money but we can lose equipment because of an attack. And maybe the worst case, it can start to harm individuals in, you can imagine if a nuclear reactor is, if there's some attack on the computer system and that computer system controls the heating and the cooling and so on, then the worst case is a meltdown and of course that has catastrophic impacts. So there's a wide range of impacts if a breach does occur. We're not gonna talk much about them, I think you can think about different impacts from very low to very major impacts. In the topic on IT security, we, you, I, you don't, I cover more aspects of well, how would organizations measure and predict what the impact of a particular violation would be but we will not get into that in this course. This course is gonna focus more about the network security part of community, of computer security. So we wanna try and arrive at some definitions and some classification of the things that we need to consider in network and computer security. What's OSI? Anyone seen it before, the acronym? ISO backwards? Well, OSI and remember last semester we talked about the five layer TCP IP model. There was another one before that which was a seven layer model called the Open Systems Interconnection, OSI model for communications and the organization that created OSI is ISO. ISO created OSI. Why is it relevant here? In creating a model for communications in networks, one aspect they need to consider is security, security of communications. And many years ago, they come up with some, some definition and models of, well, what do we need in terms of security and networks? So that's why we introduced this here because it has a few nice definitions of network security. So we're not too concerned with OSI, with ISO and there's another organization, ITU, who work with ISO. I'm not too concerned about that. I'm concerned about getting to some of the definitions and terminology that they introduced. This organization is ISO and ITU created some definition of security and computer networks. And some aspects that they defined were, they classified types of attacks different security mechanisms and the services that computer networks should provide to users to prevent the attacks. The aims of, well, how do we say that? The services that the users should be offered such that the network works correctly.  A threat is a potential violation of security. So something may go wrong, that's a threat. So a threat could be that someone guesses the password of my login for SIT. An attack is when they actually do that. They carry out the threat. An attack may result in a violation. A threat is something that can go wrong. An attack is an attempt to carry out that threat and the attack may be successful or not. So ISO, ITU created some definitions and they spoke about a security attack. Some action that attempts to compromise the security of information or facilities. So something that someone does that tries to defeat the security of information, for example, files or information that we store, or facilities like a computer, parts of a computer system or network. A threat is a potential for an attack to occur. So we may have security attacks on systems. Security mechanisms are the different methods that we have available to prevent attacks and if we can't prevent them to detect attacks and if we detect them to hopefully recover from attacks. Ideally, we'd like to prevent attacks, stop them from happening, but in practice that may be impossible. So if an attack does happen, we'd like to at least be able to detect it and then do something about it. We will, towards the end of this topic, list a set of security mechanisms and in fact this course goes through those mechanisms. A service, we want to use a set of security mechanisms to enhance the security of our information or the security of our facilities to stop attacks. So I want to provide a service such that attacks are difficult or preferably impossible. So in the next few slides, we'll list first some attacks or classify different types of attacks, then we'll classify different types of services and then in the rest of this course, we'll really look at the different types of mechanisms and they'll all come together, attacks. And this is related to computer networks, but a lot of it also applies to just stand-alone computers. A computer network is multiple computers communicating with each other. First, we'll classify attacks as to either passive or active. And within passive, we'll see there are two types of attacks, releasing the message contents and traffic analysis. And in active attacks, there are four types, masquerade, replay, modification and denial of service. We'll go through those six. So really we have six types of attacks. Two are passive, four are active. Let's go through those six and then we'll come back and compare active versus passive and explain them. These examples of attacks are from pictures from the textbook. And in a communication system, we have someone wanting to communicate data to someone else. So Bob wants to send data to Alice in this example. Bob and Alice are normal users of our communication system. So in this picture, this cloud represents our communications network. It's called a communications facility here. So the normal situation is in this case, Bob sends a message to Alice. If there's no attack, then that's all that happens. Bob sends a message to Alice. Let's say Bob wants to keep that message secret or private or confidential. Bob's sending a message to Alice and he doesn't want anyone else but Alice to see that message. Then an attack on that form of communications, if there's another user, a Darth in this case, our malicious user, the attacker, that somehow gets a copy of the message that Bob sends to Alice and is able to read the contents of that message. That is an attack on the communication system and the name here is just releasing the message contents. That is, the contents of the message Bob sends to Alice is released to someone who shouldn't have it. And this is a common attack that people think of in security. That is, we want to keep information confidential. Such an attack makes the confidential information public or available to those that shouldn't have it. How do we stop such an attack? What mechanism do you think we have that we can stop such an attack? I'm sure you've heard of it. Again, I hear, all right, many answers, sorry. MD5 is what? Three letters, three letter acronym, a hash algorithm? No, we'll come back to a hash algorithm. We'll see it is used in some things. But it may be a simpler thing. I think you've heard of and you probably use it on a regular basis, but you may not see it. How do we keep messages secret? We encrypt them, okay? That's all, that is, we use encryption. A cipher is just the name of, is what we call an algorithm, an encryption algorithm or an encryption cipher. So if Bob wants to send a message to Alice across a network, such as the internet, then we normally assume that someone else may be able to see those messages being sent. Let's say my computer is Bob and Alice's computer is in the US. So when I send a message to Alice, then it travels through the SIT network, through the ISP inside Thailand to some ISP that connects to Japan and then across the Pacific to the US and so on. So my data travels through many other people's networks. I don't trust them. It's very easy for someone who owns and operates one of those networks to intercept the messages and see the contents of them. And in fact, if I send this through the SIT Wi-Fi, it'll be very easy for you to sit here on your laptop or even mobile phone and intercept my message as I send it to the US. So if Bob normally sends a message to Alice, then it's very easy for someone to intercept the message and get a copy of the message. So the way that we try to prevent such an attack is that before Bob sends the message, he encrypts the message and then sends the encrypted version of that message. Alice receives the encrypted version and Alice decrypts the message. And to decrypt, she must have some key. So there's some key that Alice needs to know which usually Bob knows as well. So Bob and Alice have a shared secret key. Bob encrypts, sends to Alice, Alice decrypts and gets the original message back. Darth intercepts the encrypted message. Even though he can see the encrypted message, he cannot see the contents, the original message, unless he can decrypt that message. And to decrypt, he needs the key. So that's what encryption relies on, is making it hard to be able to decrypt a message without having the key and then making sure that Darth cannot get the key. We'll spend several topics going through how encryption works. So that's one of the mechanisms and a very common mechanism used in computer security is encryption. At this stage, we're just looking at some of the attacks. Let's say that Bob does encrypt his messages. He's got an encryption algorithm. Before he sends them, he encrypts them and Alice can decrypt, Darth cannot.  But there's another type of attack that can occur called traffic analysis. In this case, Bob and Alice are not married. And late at night, Bob sending messages to Alice, someone else's wife. And he shouldn't be, okay? He doesn't want other people, both of them don't want other people to know that they're communicating late at night, okay? And they're smart. They encrypt their messages so that no one else can see that there are some love messages between Bob and Alice. But Darth still intercepts the messages. Maybe Darth is the husband of Alice. He intercepts the messages and he cannot see the contents. So he doesn't know what Bob and Alice are communicating. But he can realize that they are communicating at a particular point in time. And sometimes that's enough to be useful for an attack. To not realize what the contents are, but to realize that two entities are communicating at a particular point in time and maybe with a particular pattern.  Or maybe from a different example, a law enforcement agency is Darth, a police force or some other agency. They are monitoring communications between some criminals. Those messages are encrypted so they cannot see what the criminals are communicating. But they can at least know that they are communicating. And maybe the pattern of communications leads to them working out that some other things are going to happen. Maybe a terrorist attack is going to happen in the future based on an increased frequency of messages between those people. So analyzing the communications without seeing the contents is also an attack. Encryption doesn't stop that. How do we stop that? How could your Bob or Alice, okay, what could you do such that Darth cannot work out any patterns of your behavior based upon your communications? How would you hide the patterns of your behavior from someone who can easily monitor the communications? Encryption doesn't help. Encryption, Darth can't read the contents but he can still see you're communicating at midnight or you're sending a thousand messages between a person that you shouldn't be. How can we hide that or stop that? Maybe I gave it away. You want to somehow hide the pattern of your communications. So assuming someone can monitor maybe you want to send some fake messages at different points in time to hide the patterns. So instead of sending thousands of messages every Saturday night, make some pattern of communications that spreads the messages over time. So it's harder for the observer to observe any pattern in the communications.  Do not send the messages instantaneously that have them delayed over time. So that's a second form of attack. Consider both of these attacks. Look at the picture. Let's assume there was no attack. In this case, Darth wasn't there then the normal communications is that Bob sends a message to Alice. Let's say Bob sends one message Alice receives one message if there was no attack. So the normal users Bob sends a message Alice receives a message. When there is an attack Bob sends one message Alice receives one message. Nothing changes from Bob and Alice's perspective whether there's an attack or not. And that's what we call a passive attack. From the perspective of the system of the normal users, the normal communications network when we introduce the attack nothing changes compared to the normal operation. With the attack Bob sends one message Alice receives one message. Without the attack it's exactly the same. So the attack doesn't change the system operation. So we call that a passive attack. It's the same in this case. Let's say Bob sends 10 messages to Alice in the case of no attack. Bob sends 10 messages Alice receives 10 messages. If there is an attack it's the same. Bob and Alice send and receive the same number of messages. It's just that Darth also receives them. So the attack doesn't modify the system operation or the system resources. These two are passive attacks. The next four are active attacks. You'll see that when the attack takes place the normal behavior is different from the perspective of Bob and Alice. Masquerade. What does it mean? Masquerade. Mask to pretend to pretend to be someone else. In this case. To mask yourself or to pretend to be someone else in terms of network security. So this is an attack. Alice is the works in the accounting office and does the pay slips for everyone. And Bob is the employee and sorry, Bob is the director of SIT and he issues commands to Alice to increase Steve's pay by 10,000 baht per month or to decrease if I do a bad job. So normally Bob sends an email to Alice saying at the end of the month whose salary to increase and decrease and when Alice receives that she changes the amount you get paid. Darth pretends to be Bob and sends an email to Alice saying I am the director. Please increase the salary of Darth by 100,000 baht. So this is one user, Darth, the malicious user pretending to be Bob. Darth sends a message to Alice setting the source address to be that of Bob. Alice receives the message thinks okay, the email is from Bob therefore I should increase the salary of Darth by 100,000 baht. Darth pretends to be someone else and performs an attack on the system. Any questions about a masquerade attack? How do we stop it? We can't really stop it. We cannot prevent someone from sending out a message in our network normally but we can detect. How can we detect it? Alice, let's say it's an email. Alice receives an email. I don't have a demo today, maybe next lecture. It's very easy to fake the source address of an email. That is I send an email and say from Tanara and you receive it and it's from Tanara. And for most people it looks in the email client it will say from Tanara at SIT. It's very easy to fake the source address of an email. So in that case we can't really prevent someone from sending fake messages. What we need to do is make it easy for Alice to detect when Alice receives a message she needs a way to be able to check is this message really from Bob or is it from someone pretending to be Bob? We need to somehow authenticate the sender of that message. And probably after the midterm we'll look at some mechanisms for doing that. We'll start to introduce hash algorithms, message authentication codes and digital signatures we'll arrive at. That is the source really needs to sign the message. In the same way with a piece of paper you sign the message give it to someone and they know it's from you because the signature acts as some proof it's from you. Well we need that in computer systems as well that someone can create a message sign it such that when the receiver receives it they can verify the signature to prove that it did come from the original source not from someone else. So we'll see the mechanisms of digital signatures and related techniques in this course. It's an active attack what if there was a no attack? How many messages does Bob send if there was no attack here? Not nothing he sends nothing no messages. And of course Alice doesn't receive a message if there was no attack. But the introduction of the attack in this case means Alice receives one message. That's we say we've altered the system behaviour this is an active attack something changes because of the attack.  There's no way normally with the normal internet protocols to confirm that the message that you're receiving from someone is who they say they are. Let's keep going through the next three replay attack. Bob is the director of SIT. Again he sends a message to Alice increase the salary of Darth by 10,000 baht. Fine that's an intended message. Darth did some good work increase the salary of Darth by 10,000 baht Alice who works in the finance office increases his salary for that month. That was normal operation. But Darth intercepted that message and took a copy. And next month Darth takes that copied message and sends it on to Alice. The message was signed by Bob the director. What Darth did was took a copy and replayed that same message some time later. So the next month Alice receives a message it's from Bob it's got Bob's signature Alice confirms it's from Bob saying increase the salary of Darth by 10,000 baht so now in the next month he gets a second salary increase. This is a replay attack where the attacker intercepts a message a valid message and some time later replays that message to achieve some goal which is breaking the system. So sending a valid message at some time later is a replay attack. How do we stop it? Again you can't stop replays normally that is it's easy for someone to intercept and you can't stop them from sending again we need some way for Alice to detect that the first message was the original, the valid one the second replayed message is just a copy of the original one let's ignore it. We could use some sequence number if we receive two messages which have the same sequence number ignore the second one or some time stamp I receive the message and inside that message contains today's date one month later I receive that same message for the date from one month ago ignore that because it's too old it becomes invalid after some time so we'll see some mechanisms that deal with stopping replay attacks modification Bob sends a message decrease Darth's salary by 10,000 baht before that message gets to Alice Darth intercepts changes the word or the letters D DE to IN from decrease to increase and forwards the message on to Alice Alice receives it and increases the salary so this is modifying the message along the way Darth must intercept it's different from before where they intercepted but the original travelled through to the destination to intercept and make sure the original doesn't get to Alice and then modify and send on to Alice again an active attack why is it active what's changed the contents has changed if there was no attack Bob sends a message decrease the salary Alice would receive a message decrease the salary Bob sends a message decrease the salary Alice receives a message increase the salary something has changed the message has changed in this case we call that an active attack last one denial of service Alice has disappeared Alice is a computer server a website for example Bob normally accesses that website to get his job done accesses the server to do things the service users does some things to overload the server maybe he sends many messages to the server so fast that the server overloads and it cannot process any messages from Bob as a result Bob can't do his normal job this is a denial of service attack it's an attack that denies the normal users access to the service or the server how do we stop that it turns out it's very very easy to perform denial of service attacks and quite difficult to stop it without disrupting the normal users let's just jump back to this summary of passive and active so passive we make use of information sent but we don't change the system resources we intercept and look at the message contents but we do not change the message or we do not generate new messages traffic analysis we just observe the messages being sent the frequency the timing passive attacks are hard to detect Bob and Alice are communicating it's hard for them to know that Darth is listening in and intercepting it's very hard to detect but quite easy to prevent by using encryption or adding some extra messages to hide the behavior passive attacks change the system resources or the system operation they are hard to prevent that is it's hard to stop someone to send messages but easier than the passive attacks to detect so there's trade or there's differences in terms of prevention and detection so usually we try to prevent passive attacks and detect active attacks any questions on attacks so broad classification of the main types of attacks in computer networks and also relevant for most computer systems in general I will sometimes use the word I will not use Darth very often but we'll talk about the attacker or the malicious user what other words do we hear for someone who does this a hacker a hacker is commonly used to refer to someone as the attacker but unfortunately the word hacker has other meanings some nicer meanings a hacker can be someone who plays with hardware to build new things out of existing things so sometimes we avoid the word hacker but an attacker malicious user they don't need to be a bad person it could be some law enforcement agencies some police force for example detect and stop crimes just because they are the attacker or malicious user doesn't necessarily mean they are the bad person in the world but just with respect to the communications they are doing something to perform an attack so there are different types of attacks possible we've mentioned some mechanisms encryption digital signatures and there are other mechanisms some of those mechanisms come together to provide services there are a couple of definitions but I'll go direct to the third point here security services implement security policies and are implemented by security mechanisms so what that means is we use different security mechanisms to provide a service to our users and that service is provided to achieve some policy and the policy is usually from some organization so the policy for SIT may be that no one can see the grades of no student can see the grades of any other student that could be the policy of the organization that every student's grades should be confidential to that student other students shouldn't be able to see them so that could be the policy so we look at what security services do we need to implement that policy and the next slide will list the security services and those security services will implement using mechanisms in this course we will not talk too much about policies we'll go direct to the services and then more details about the mechanisms there are different types of services or different classification services which are commonly used to talk about what we try to offer our users in securing a computer system some people have different names for them but we will use these in this course and you will remember them because there will be quiz questions about them they're important these are the things that we want to provide our users if we operate a computer system authentication we want some means for assuring that the person we're communicating with is who they say they are so we saw there's an attack if someone sends me a message if they pretend to be someone else I need some way to check that they are who they say they are that service is called authentication more precisely we can talk about peer entity authentication so when we're communicating between two entities they appear with each other so when someone sends a message to one entity that entity wants to authenticate the other peer in the communications the other entity sometimes we'd like to also authenticate the data the data origin that the data we don't care who it came from that the data is correct came from valid origin what's an example an example of data origin authentication is that some emergency systems are deployed such that when there's an earthquake the monitoring devices send out a message to people to say there's an earthquake here and maybe that means there's a tsunami coming so you can evacuate so there are computing devices so in the sea and monitoring when they detect the earthquake they automatically send a message when we receive such a message we'd like to authenticate that that's correct data we'd like to authenticate that it's not fake data that it's true data it's not some data that's made up that causes us to evacuate when we don't need to evacuate so sometimes we'd like to authenticate the data that it came from a valid source another service we'd often like to provide in both computers and also computer networks is access control our computers have resources that we provide to users we want to control who can access those resources so we prevent unauthorized use of resources for example we have a website and some parts of that website are public to everyone but some parts of that website should be private and you need to log in to access that part of the website the mechanisms to protect that part of the website is called access control you use it commonly on computers access control on files access control on different features in the computer networks it's commonly commonly implemented by firewalls a firewall controls who can access a particular network so that's a common service needed data confidentiality of course is quite common we need to be able to protect the data from unauthorized disclosure that is often we want to make sure that no one else can see our data keep it confidential that's a common one for related data integrity we want to be able to make sure that the data that we receive is exactly as the source sent it it's not modified along the way it means we maintain the integrity of the data availability jumping to number six making sure the system is accessible and available to the people who should be using it so if it's a website that's used for registration inside SIT then it needs to be available during the registration period so all the students can register on time if for some form of an attack it means the registration website is not available during last week then there will be some severe disruptions in SIT so availability is the service that we want to provide it's to stop denial of service attacks number five non-repudiation this is the service of trying to stop people from denying communications took place consider we're using our computer network to perform financial transactions exchange money or pay for things so what happens when you go into a shop and you buy something how do you prove that you bought that or you've paid your money for a receipt you give them money they give you a receipt and you can use that receipt as a form of proof to say that you've actually paid for this object that you're taking we often want similar services in computer networks we perform some transaction we send a message we'd like to be able to later prove to others that that message was actually sent or from the other entity's perspective that the message was received for example you need to submit your assignment by email to me so you send the assignment to me I don't get it or even worse I'm a nasty teacher and I say I don't like you I didn't get your assignment I'm going to give you a zero what do you do you need some way to prove that you did send it so we'd like some way to prove that you did send it or the other way you send you send what do we want the opposite direction you want to be able to prove that you received a message some proof that you've received a message is the other thing so non-repudiation is this service of trying to protect people or protect against denial of communications make it hard for someone to say no I didn't receive it or no I didn't send it that's what non-repudiation is about security mechanisms we use the mechanisms to try to implement these services and such that we prevent the attacks so we use mechanisms to implement services such that the attacks can all take place there are many types of mechanisms there's no one mechanism that provides all six services so we need a combination most mechanisms make use of cryptography the title of this course includes cryptography and the next topic and several topics following that we'll look at what is cryptography cryptographic techniques this lists a few examples of mechanisms but maybe the next table is a nice summary and nice place to almost finish in the rows we see in this case there are eight services it splits some of them out so authentication is split into two different services authentication of the peer and the authentication of the data origin and confidentiality is split into two confidentiality of the data stopping the release of the message contents and traffic flow confidentiality is stopping traffic analysis even if someone cannot see my messages they can still analyze my traffic so traffic flow confidentiality is trying to make it such that someone cannot analyze my traffic so they come together the column shows some common mechanisms used to implement those services so to provide confidentiality we commonly use what's called an encipherment or we usually just call encryption we encipher the data or we encrypt the data to provide authentication we may use a combination of mechanisms we use encryption or encipherment digital signatures which we need to explain in this course and maybe some exchange of messages to authenticate the user we'll see that there are mechanisms called data integrity which use encryption techniques and cryptographic techniques so in this course we're going to go through really the cryptographic techniques to implement most of these mechanisms these mechanisms then come together to implement these services that we want to provide our users questions so key points from this topic CIA attacks services we haven't really got into the mechanisms yet we've mentioned some but I will not ask you in the quiz what are all the mechanisms but what are the services what are the attacks passive versus active and these general concepts of confidentiality, integrity and availability are important we're moving to cryptography and the way that we study cryptography in this course is that there are many complex algorithms to encrypt information very hard to cover those algorithms but they are based upon some principles that have been around for a long time so the first part will we look at the old ciphers the old algorithms for encrypting information old starting from several thousand years old Caesar cipher and then progressed through some old nowadays they are ineffective ciphers with computers they are very weak but they demonstrate different principles of how do we encrypt data and we'll finish today with an example which will set us up for next lecture here's some encrypted data find the original data this is a simple cipher it's based on what's called the Caesar cipher where we shift the letters so we call this it's not easy to solve quickly but I think with a little bit of thought you will we call this this is the encrypted data we'll give it the name ciphertext we'll see this to find next topic cipher, a cipher is an algorithm for encrypting and similarly decrypting so the encrypted form of our message is called ciphertext in this case it's k-h-o-o-r and to get this ciphertext I started with some plaintext we'll find that in a moment the plaintext is the original message unencrypted we encrypt it and we get ciphertext and the most common form of encryption algorithms the way that they work is that we take an algorithm called a cipher and in this case the cipher we used is what's called the Caesar cipher I always spell it wrong based on Julius Caesar one of the Roman emperors and we take the plaintext we apply an algorithm the algorithm is called the cipher in this case it's the Caesar cipher and combine the plaintext and a key a secret key and the key is secret if you know the key you can decrypt if you don't know the key you cannot decrypt well that's the idea of encryption in this case the cipher is not so good that even if you don't know the key I think you may be able to find what the plaintext was so the cipher is the Caesar cipher you may not know what it is yet you will next lecture some of you do the ciphertext is k-h-o-o-r your challenge as the attacker is two things find the plaintext even better find the key because if you know the key you can find the plaintext and the Caesar cipher is a cipher if we think of the English alphabet A through to Z where the key determines the number of places we shift the character by to get the ciphertext for example if the key is 3 the letter A as plaintext is encrypted to get the letter A to B to C to D the letter D is ciphertext we shift A 3 positions to the right and we get D so the output would be D as ciphertext so I will not ask you to guess the key how many possible keys are there so the Caesar cipher English alphabet 26 letters if we have a shift of 0 plaintext letter of A becomes ciphertext letter of A so if my message was security and I encrypt it with a key of 0 the ciphertext is security it's not so good encryption but if I have a key of 1 it means the S in security is encrypted and shifted to the letter T E in security shifted one position to F T, F and so on so the number of possible keys is 26 in this case one of them is not so good 0 the key in this case is 4 from memory now I find this plaintext shifting up is for encryption so encryption takes say the letter A and if we shift by 4 positions produces the letter E we move to the right shift up so decryption should be the other way I think I've made a mistake the key wasn't 4 it was 3 sorry because if you decrypt it doesn't make much sense but it's 3 so be careful you want to decrypt not encrypt encrypt takes a letter let's say A a shift of 3 produces ciphertext of A goes to B C D we go to the right decryption goes backwards K H O O R and a quick helper maybe just so you can remember the alphabet but the numbers makes a little bit easier we had K a shift of 3 positions mean the input must have been H if we start with H and shift it to the right 3 positions we get K therefore if we start with a ciphertext K to get the original plaintext we must shift back the opposite direction to get H so K decrypts to H H decrypts to E we had K H O O decrypts to L and we had R decrypts to O hello we'll see that the challenge of the attacker is given some ciphertext given the cipher find the key and or the plaintext with encryption we assume the attacker will know the ciphertext the encrypted form we also assume that they know the algorithm used it's usually the practice that the algorithm is known to everyone so the attacker knows it was Caesar cipher we have K H O O R the attacker has 2 challenges given that find the key and or the plaintext if you find the key you can easily find the plaintext if you find the plaintext sometimes you can get back to the key but not always for different algorithms so what we'll do on Friday Friday we will look at ciphers similar to this very simple ones with some examples to start to demonstrate the concepts of encryption


Hi, I am in Hasraman and I am the DCL STEM December student of the month. I am part of the biomedical CTE program and I'd wanted to choose the CTE program because ever since middle school I've always been interested in biology and science as a whole and I've wanted to pursue it further in high school And eventually into further education. Now that I'm here as student of the month I gotta say that it's quite a big surprise. You know, I've always been focused on my studies So I never thought it actually become the student of the month. I am part of the HOSA program for biomedical students And I've also part of the environmental club. So yeah after school I mostly focus on well Homer obviously, but I also like to help out my dad at his restaurant as Like a cashier and taking orders and stuff on the weekends mostly. Well after high school I'm probably going to enter an in-state university such as Rutgers And I plan on focusing on a pre-med program so I can eventually work my way up to becoming You know a general practitioner game my MD One fun thing about myself is that I've been recently getting into drawing and well I'm not exactly the best at it, but it's fun for me to do It helps relieve some of my stress from school and I don't know I just generally like trying out new things. It's fun Well, I'd like to first thank my parents and my sister for encouraging me helping them out when I just feel Stuck or overwhelmed of school. I'd like to thank my guidance counselor Of course for putting up with a lot of the things that happen in school helped me Helping guide me through like college applications and all that and I just like to think like all the friends I've been able to make at DCL STEM Academy because I've came into DCL STEM Academy from of course my local high school And I didn't really know anyone coming in but everyone was just really kind and I'm glad for that


So, my name is Michael Brown. I am the lead technologist for our next generation chassis controller at Dell. Still getting used to saying Dell EMC. So, you'll hear me still but just say Dell once more. And what I'm here to talk to you today about is updating your Yachto environment and setting up strategies or setting up one method that we have used in my group to keep ourselves up to date and make it a little easier. So, as I said, questions are important. Feel free to raise your hand anytime. Ask a question. My job is to keep the thing going and end it on time so I will keep it. I will cut things off if I am starting to go a little bit long. So, who am I? I've been at Dell, now Dell EMC for 17 years. And I am the, basically you could say I'm the Yachto architect of the Yachto environment at Dell. So, kind of a funny story how I got into that. I was on the Linux team for a very long time and we had a couple of other folks on the embedded side that did a lot of evangelization around open embedded and Yachto. And anybody that ever came to me, I did a lot of containers, VMs, bootable ISOs, that kind of thing. Anybody that came to me and mentioned the word embedded or anything non-X86, I said, go talk to Sean Hudson. By the way, he's here. He's presenting. He has a couple of BF sessions. He's a great guy. I recommend checking him out. But he worked at Dell and then he decided to leave. Three weeks later, I get a call from the director of the embedded team asking, can I come over and lead an effort to port away from our homegrown system and use some kind of standard base, which I had been advocating for several years. Kind of pointing at Sean to do that. But that's how I became the Yachto guy. So currently working all over on next generation stuff. I can't get into too much details about stuff that's not shipping, as you guys probably know about. But I can talk about the development process. So the problem, as we talked about a little bit before we started, this is about keeping your development environment up to date. It's not talking about device updates. There's several other sessions in this talk that talk about actual updating your device. And I recommend going to them. I'll probably be a few of them.  So that's what we're going to talk about today. Keeping your development update updated is very hard. As we kind of saw at the show of hands before we started, the majority, I would say, of people in this room are using not current Yachto. A lot of reasons for that. One of the things is kind of inertia, fear of the unknown, and breakages. So when something breaks, if you break a development environment, you're putting teams of dozens, possibly hundreds of people, kind of out of a job for a period of time until you can get that stuff fixed. So as you can imagine, if it happens once, happens twice, people get gun shy about updating their environment. And it happens pretty rarely. So on the other extreme, when you get a really out of date environment, we're shipping IoT devices that we talk about in this conference, we're shipping embedded, in my case, embedded server management. We're shipping stuff that's really old. And if you get a security vulnerability in one component, sometimes there's interlocking dependencies. If I want to update open SSL, well, I need a newer version of GCC. It goes on and on, and you get into this situation really quickly, where you physically can't update to fix a security vulnerability. I did update a system ported into Yachto two years ago. We were on a 2.4 kernel. So it can get kind of hairy trying to update stuff that's that old. So I'm going to talk about that on the next slide. So I'm giving this talk to specifically talk about Yachto, but the concepts I'm going to talk about here can actually be applied on most systems. I have one slide, it's the big idea slide, that you can take that and kind of cookie cutter it. So Dell, we put what I'm going to talk about in this slide. We put this in place two years ago with our next generation. So we've been in development for our next generation of server products for a couple of years now. And at the beginning of that process, we put this system in place. And we've used it to update through four major Yachto releases in our current head master development environment. So we've gotten this pretty much down and have a benefit slide at the end. I need to save some material for that. So we've used this to keep ourselves up to date. I have to admit right now that we are certain right now sitting on 2.0 plus a little delta because the guy that was heading up this project, he was a new college hire. We put him in charge of this. And because of the fact that he updated the environment, he got familiar with everything. And he became one of our go-to guys and became really valuable and got a raise. And so do this stuff for career advancement. And he ended up getting pulled off of that to do other things because of the knowledge you gain directly from doing this. So this might seem like a drudgery type of thing. But from a career advancement perspective, it's a really quick way for a new guy to get familiar with your entire system. So the Dell EMC firmware team, specifically the people using Yachto, all of our embedded server management, so our iDRAX from our 12th generation onwards are all running Yachtos. The chassis management controller and all of our chassis, the M1000E, the Vertex, all the other chassis variants are all running on a Yachto base. And all of our in development systems are all for our next generation to be released servers. And chassis are all running on Yachto. Of note, we've actually come up with a nice little way to have one code base that we build all of these different products on starting with our next generation stuff. It actually get more bang for our buck because we can update our Yachto base once and update several products. So the question was how many developers you're talking about? Liga won't let me tell you, sorry. It's a large development team. So our Dell Yachto environment, we basically have Pokey plus MetoE, which hopefully everybody here kind of knows that. We have roughly 300 individual components that we use, and those are all individual standalone components, each with their own auto tools, with their own bit bake recipes, et cetera. And basically I wrote almost all of the recipes, all the auto tools and everything, so any questions about that stuff I can pretty much answer. So we have about 300 Git repositories to build all our products. Managing that is a little bit challenging. I don't know why that's blue, interesting. Anyway, it's not supposed to be highlighted. Export error. So we use the Android repo tool. When we started this back in 2012 is when we started the porting effort, and really we had Git sub modules, which at that time I couldn't wrap my head around, and we had the repo tools, the only real two tools we had to manage hundreds of repositories. So we chose repo tool, and heavily based our environment around the repo tool to a lot of success. Today there's other tools that can do equivalent things. So if you're starting out today, you can start with the repo tool. There's a couple other ones I heard about. It's names escape me at the moment. Stress from presenting. So our environment is a full source build. So every component is all built from source. So every developer checks out and builds everything from source. So we leverage things like the YachtOS state cache to speed that kind of thing up. From the way our tree works, we have, check out at the top, we have the 14G, you create a directory to check your stuff out into, and we have a directory structure, where we have Poke, MetaOE, we have our own custom layer MetaDRAC, where we have all of the Dell BitBake recipes. We have a policy in place, and this is a little thing that I highly recommend, we do not allow check-ins to our copy of the Poke repository. So we always use straight standard out of the box upstream Poke. And then we do all our stuff as BB appends or writing our own classes. And then so all of our custom BB pans or all of our custom bit bake recipes are all in the MetaDRAC directory. External source, so I haven't really seen many people do it this way, but we check out all of our source tree, all of our Git trees under individual and external source. This talk isn't about that, so I won't go into too much detail on it, but we leverage a custom written external source BB class that I wrote before the upstream Yachto got one that lets us do our builds of our components inside of our Git repositories. And then our builds are separated out since we build several products from one source tree, you'll change your directory into one of the build subdirectors for the product that you're trying to build for and do a build. So this is kind of like the way the development environment is set up and you'll kind of need to understand that to see the next part. Question. So the question is copies of public repositories, do we copy? So internal to Dell, firewalls are a thing, so anything that we build, it's like Poke, Meta, we have our own internal mirror, and I treat those as if they are the public. And then we have a few repositories that we just mirror and so there's like maybe a half a dozen to a dozen, so like the kernel, Poke, Meta, OE, and a few other things like that. Most of the other things that are external Git repositories use the standard Poke Git mirroring tar ball where you'll download a tar ball of their source and plug it in. So I've cut out a lot of that stuff just for time. So branching, we have a naming convention we use for our branches, REL for release slash 14G slash master, it's our current end development. And then we don't have any branches off that yet but our other products that are already released would have a REL 14G 1.0, 1.1 and master branches. So we have a pretty hierarchical naming convention so we have can group all of our tags, group all of our branches and you can easily see what's related to what. From a reusing, for example, with Poke, we don't use master at all in any of our repositories because it conflicts with people's, if we're pulling in an upstream repository and using master, it's kind of hard. So I like to take their branch and pull it into our naming convention. So that's that stuff. So, the big idea. We have a separate build called Poke Next and you're like, okay, we came here for this. But it sounds really basic but it's really the core of keeping yourself up to date. So, the core requirements and then the next slide, I'll show you the kind of directory structure. We have a parallel build structure. So you can build, I pointed to the external source directory. So, nobody in this room is shipping Yachto. People in this room are shipping your app. You have your code, you don't care about Yachto, you care about your app. So this is a parallel build where you build your code against either the upstream Poke that you're running on or Poke Next. And because we set this up so that you can do either or, you can get your code to run on both of them at the same time. This also means that there's no pressure that you have to have that, I have to get this working within a week or two weeks or you can update the Poke Next and if there's a bug with it, it's not stopping anybody from doing their work. They still have their normal Poke. So, small units of work, once you get your code working against Poke Next, you do dedicate one of your college hires to do updates of Poke Next. Once every three weeks to six weeks is what we found kind of works. These are small incremental updates. You're basically just doing pulling in the baseline from upstream and usually nothing will break. So if you do every three weeks, you do a get fetch and then push into your Poke Next, the new version, it'll just build. In our case, if upstream updates a version of a component, we might have to update a tar ball because we can't access the external world. So the every three weeks involves pulling down a new tar ball. In our case, this can work several different ways. The way we've done it and what I'm gonna show you in the slides is we have two separate source control repositories for Poke and Poke Next and we control the flow of code between them. So the benefits of this is that you can work on the hardstuffs, so a Yachto update breaks or is incompatible, maybe there's a GCC update.  You can kind of do that in a way that works with the current Yachto release while making it forward compatible with a new Yachto release on your schedule and when it's done, then you can switch over. So we're talking about parallel build structure. We actually have this .next directory which will be hidden from the normal developers doing an LS so it doesn't confuse them. But we have another build directory under there and so you can change directory to build slash CMC under .next and the BB layers are all set up to pull from these Yachto repositories but the common code base. So we can do, so developers can do a build against the next version of Yachto or they can do of the currently working version of Yachto. So you have one guy that's just every few weeks, he does this update. He sends emails out to everybody who has new compiler warnings or new things that they need to fix in their code base in the .next and then the development teams can schedule this. So Shilpa Hins, who's using Agile? Okay, so you have your sprint planning and your sprints so the person doing the Yachto next updates can then write stories or write defects against the code for Yachto next and then you can plan this out just like any other development task. It's not, the updates can tend to be unpredictable. You don't know what kind of works gonna come your way. This kind of evens that out. So the get repositories. So basically, because we're using the repo tool and I like to keep all of the repositories, we check out on one branch. The way we do it is we have a separate backend get repository for Pokey and Pokey Next. So we can continuously update this version with the upstream version and then once you have this next version to your liking which I'll talk about some branching timelines, once you have this to your liking you basically can just flip it into so using the repo tool, you can just change repository manifest to then point to this repository or you can push code between the two repositories. It's kind of your choice. And repo tool, just the, in some people I've talked to, the repo tool seems really hard and difficult to use. It's actually fairly simple. You have an XML file. Here you can see we have a default revision. This is the branch that we're on. And then we have the Pokey directory and we're pointing it at that idrack slash pokey dot get repository and we have our dot next repository. So this is just a small snippet of our actual manifest for illustration purposes. Oh, questions? So the question is do we move Pokey next to Pokey between releases or at release points which is the next slide. I'll go over that in a second. You had a question as well? Yeah, so the way it works is internally we have a mirror and that mirror, when you update that mirror if you change anything on it it completely blows it away and re-mirrors, right? So that upstream mirror has just what the Yachto project get that Yachto project has. All the Morty and Korgoth and all those funny names that I can never remember. In fact, I had to update the slide last night to be current and had to actually go with the Yachto project and look at the Wiki to get the names. We have our own copy and what you can do with Git is I can make a branch and I can make my repository just have one branch and have it be just one branch from the source. So the Morty branch in all of its history in the upstream becomes my REL 14G master and I have nothing else from that repository. And I can update that using a Git pull from my mirror or from upstream. And from my developers perspective they don't see any difference. Answer your question? Okay, let's go to the, so this is the kind of timelines we're talking about. So this is kind of like entry level, let's keep majorly up to date every six months type thing. We're gonna go into a little bit more fine grain after we got this concept down. But what we have here is at the very bottom we have our upstream Pokey. So there's hundreds of commits per day to upstream Pokey. We pull them in on a regular cadence, three weeks, six weeks into our .next Pokey repository. So Yachter releases are six months long. And so for usually around four months or so of that kind of ignore it mostly, do a few updates, make sure it works okay. But coming on that four, five, six month mark when we're coming up on the release we try to pick up the cadence on this so that we are kind of up to date with the upstream. Couple of cool, nice reasons for that. If we have a problem with something upstream is doing we'll catch it and be able to submit a bug report and get it fixed before it gets set in stone. So this is one of the big reasons. And every six months of work this fits really well into an agile planning process. You can put stories in and you can kind of plan this out. And from 2.1 to 2.2 you can't predict how many breakages you're gonna get. But you can kind of plan out the kind of work you'll do per sprint and kind of guesstimate on the number of breakages and the more you do it the smaller the breakages are gonna be. So the more fine grain you get the less work you'll do and the better you'll be able to plan it. So then when 2.1 comes out we update it so a little delta, so you see the little jog in the line going up. We've updated our next repository and then I cut out one slide for time but that 2.1 up into the main repository there's a lot of slack in there and we can plan that basically around our release time frame. So we can do it immediately or if there's something important milestone where we need to do a release we can say okay we'll wait a month or so. So this is what gives us our flexibility on when we do our updates. Cause that next pokey directory is not gonna go away it's sitting there and it's buildable and we have Jenkins jobs that build it so we know that it's gonna stay working and once you get it working it stays working. So that's a kind of a principle it's not. If you got Jenkins jobs and you, I lied when I said it when it works it stays working because developers will break it but you can manage like one or two defects. If you have a Jenkins job that does a build once a day then you can file a couple defects and get that stuff fixed in a timely manner. So the question is are Jenkins jobs running automated tests and I think my personal opinion is that should be the goal of everybody is like you Jenkins you do a commit it triggers a Jenkins job puts it on hardware or an emulation and those jobs. Automated build verification is what we call them ABBT. So yeah in our world we do have a build verification test suite that runs and for the engine product I'm working on we have a full QEMU instance set up so you know right in Jenkins it fires up QEMU and starts running tests and it's really great. We actually got a lot large amount of our code based up and running before we ever got hardware and kind of amazed cool tricks to amaze your management team. So this is your branching and merging. So the nice thing about this this is great for long live development projects. So for example I said we started our next generation two years ago and two years ago I think 1.7, 1.8 was the current and without some kind of strategy for keeping that up to date we would today be in our final development stages of still using 1.7 with all the bugs and it's no longer under long-term support et cetera and looking at lots of re-validation effort to try to update it at the end of a development cycle and who wants to do that. So smaller units of work means that you can start parceling this kind of work out to your junior developers. This is a great way as I kind of gave away at the beginning the guys that you put on doing this if they're any good at all, this is a really good way for them to jump start their knowledge of how everything interacts and interconnects and they quickly become very valuable.  So it's something that junior guys can do and it gets them up to speed. You get your control over when you get updates in the production, so old way that I've seen, this is not a compare and contrast, I'm not trying to slam other methods of doing this but one other way I've seen them doing this is people have their pokey repository and they just do a git update on it and in there on somebody developers checkout and that developer hacks on it on his checkout until he gets everything working and then commits it all. Well the problem with that, lots of problems with that, A, you don't know how long it's gonna take him to get it working with the next version, B, you don't know how extensively he tested all that to make sure that everything is working the way it's supposed to before he checks it in. And you know if it sits there his code goes stale and then he has to rebase all your code on top of changes that have went in so it just becomes this kind of Red Queen's race to keep up to date on that updates checkout before you can check it in. So this lets you have control, everything's checked into version control and it's all parallel buildable and then you can work with your project management team to schedule hey two weeks from now on Friday we're moving pokey next in the pokey. From a political standpoint I mean when we put this in place it was a lot of resistance. We have old time embedded guys that just never wanted to update because they've been burned in the past and don't wanna do it.  After doing that four times now it's okay Friday's the date we're doing it. Speak now or forever hold your peace and it's people are more comfortable with the idea now. So it's a lot of it's a kind of a steep learning curve but once people get used to this idea it becomes a lot easier. Jenkins, we talked about Jenkins. I highly recommend whatever build system you have this automated build system is invaluable. We use Jenkins extensively. Okay so wow we're up to date with Pokey now but we now ship the product and now the product's in the customer's hands and we just found out there's an open SSL vulnerability. Now what do we do? Okay so we don't wanna do a Yachto 2.2 to the master in development version. Let's apply the same exact concept but now do it with a minor and I call it so we call it the dot next and the dot minor. So the dot minor is for your shipping products and you can do a <IP_ADDRESS> to 2.2.2 updates in using the same exact methodology and then so you can get those updates in do a quick build and test on them. Yachto products is in so far from what I've seen pretty good about making not breaking stuff in those minor releases. So it's a quick build verification test run it through all your automated builds and then ship it. And then on top of that if you have some people in here are making products that you ship for six months and then it's never to be seen again and that minor stuff is perfectly okay for that but my team we ship stuff we have to support for five years. So the long-term support for any Yachto release is shorter than five years. So we have to plan for a Yachto update in that lifetime of that system at some point. So we can combine these two for doing major Yachto updates on shipping products. So use dot minor to do the small updates and then you can kind of figure it out yourself. Do you want to do every Yachto or do you want to skip a couple versions? It's keeping in mind the cost benefits of those but now that you have those two concepts you can combine them and figure out the best mix for yourself. Well there's three, there's so on any branch so we've now done a release branch. So we have, and going back to my couple slides, rel 14G 1.0 master now. So in that 1.0 master now there will be a pokey and a pokey minor if it's a short thing or a pokey, pokey minor and pokey next that is specific for that branch that we can rotate through. And the rel 14G master has its own pokey copies. Do I have any special way of dealing with the pen files? So my main one that I came up with really early on is never, ever, ever check in the pokey or meta OE and we do everything by via BB pen. And luckily 99% of the stuff we can do we put in our own meta drag directory and use BB pens for it and it works just fine.  So now that we have this system in place it's conceivable that you could check in to pokey and have a, and rebase those changes on top of newer versions. It can get a little complex though and unless you have a good expert, I don't recommend it. But the main thing is in our meta drag we have our BB pen files. All the open source BB pens are in one spot. So we have a meta drag recipes OSS and then a directory for each one. So it's in one spot where we can find them. So if you're, so that's the other problem about Yachto is you have all these layers finding out who modified what where it can be a little bit challenging. So on our side we do our part to keep it all centralized. So if you have a BB pen for a Yachto or meta OE it's all under one directory or run directory structure not everything in one directory. So branching and the overview for branching for minor it's the same thing as for the next except it's more frequent. So in this case I just cut the slide out where we combine the whole thing but the pokey upstream is at top and here we do an as needed merge down in the dot minor pokey and then here you can do merges into your main shipping pokey directory several times during a release on an as needed basis. So obviously if there's no changes going into your minor pokey then there's no need for you to do a bunch of work there. So this is more of an as needed basis for your shipping products. And basically if you probably can't read it sorry the flow chart is pull changes from upstream pokey integrate into minor and build are there build issues fix them if there's our do your build verification test is it does it past if not fix them and then once you've got all that stuff you push it to your main line pokey. This whole process it takes like a day. So if you have the aforementioned really good college hire they can do this kind of thing in a day for one update a minor update minor updates are usually no problem. So that's the end of my slides have 15 minutes left and I have a quick very basic demo nothing elaborate that I wanted to walk through you guys walk through with you guys. Does anybody have any questions on this before I start to do a demo? Yeah so the question was you have to bite the bullet to get from your 1.3 Yachto up to Morty before you can do this and the answer that is yes you can put this branching strategy in place so you have your existing code base all working with your existing one dot old version of Yachto and then you can pull it pokey next and attempt to get it working. I myself did a our 12 12 G and 13 G where servers were running Yachto 1.3 and then when we started 14 G development it was 1.6 and actually did a 1.5 prototype before that so I went from 1.3 to 1.6 they things were deprecated in BitBake and you had to go do a bunch of stuff it was a big P.I.T.A. So yes you do have to figure out that first step once you've done that first one then it becomes much easier yes so like as you're just repeating what you said bits and pieces are easier than that big hit so the first part is just getting your organization your manager is your leads to sign up on this concept that we're gonna keep ourself up to date and put whatever rigor morale or processes in place that first to make sure everybody's comfortable we had a whole process with sign offs I took a couple of those slides from the initial deck we put together two years ago to get this sold and we had a whole process flow and sign offs from teams and stuff like that be accommodating however accommodating except you you're already up to date but everybody else be as accommodating as you can to get that initial update but once you've got that initial update subsequent updates become easier and easier to do so we had another question yeah I had another proposal for a talk of how we'd structure all of that but that wasn't accepted this one was but the basic, oh so the question was do we do anything cash any of those downloads et cetera so we use bb underscore node network or bb network equals zero I forget what the exact variable is but you set this bit big variable to say don't talk to the network at all under any circumstances and that's set for all of our builds and we have a separate git repository called sources that we place all of the tar balls that we've downloaded that are needed for that build in that git repository so there's a archive format for all the upstream git repositories that you can do it takes a couple of times to do it to forget how to tar it up properly and name it but once you've done that it's straightforward you everything goes into that repository it's a couple gigabytes of repository so we don't keep well we keep version history but we rotate that repository so we have for every release we have a source repository and get a new one for every release so that because otherwise the repository history just explodes but that's basically how we do it and then we have one or two developers who have proxies set up to go and update that as necessary yeah so two answers to that so at an overall level yes there's a bb underscore no underscore network equals one you set that in your local.conf and it completely disables and then there's also another one called yeah you can also say bb premiere only I think is the other variable where it will look for you can have it set up a local mirror to get stuff from you did say something that triggered me that's just one thing I forget exactly how you worded it but how you set up your recipe matters you need to have a if you have any recipes that point to an external get repository you have to have a source rev and the actual hash of the rev in there if you have it as a branch it's going to try to check that every single time it builds so in your recipe for anything that's pointing at a get repository as the source make sure you have source rev and all of the pokey in meadow we all have that uh... it's just if you have your own recipes uh... that point to random stuff make sure you have a source rev or it it won't work it'll break yes so the quest so the question is what is the time period it takes for this to happen my examples one day for the minors uh... I just have to emphasize the smaller updates you do the faster it is if you the longer you wait between them it gets a little bit inconsistent because you know if there was a gcc upgrade that went into upstream in that time period you might be looking at a lot more work however the the system itself works if you have the branches set up uh... if you run out of developer time or in our case while our developer got pulled off to do other things uh... it'll sit there and it won't be waiting for you to come back and do it right uh... so this is gonna scale with the size of your team i have a pretty large team and we can have uh... one person dedicate you know basically a couple of days uh... every three weeks to do this on a smaller team i can see how that it might be a little bit harder uh... but you know at that point he becomes more of a team effort hey it's your turn to do it this time in the rotated around again this is a really great way to become proficient at yachto fast uh... so rotating this responsibility around a small team would probably be a great way of doing that uh... our build host okay so what is our build environment run on so uh... i'm the one that set up all of our initial builds all our initial Jenkins jobs and all that stuff but we actually have a dedicated team that that i turned all that over eventually they're gonna remember figure out that i still have admin access and take that away but uh... so we have uh... we are a computer company and we have the biggest biggest piece of iron that you can imagine on that we have like a a machine of like a hundred forty four cores and uh... some a couple dozen build workers in jenkins uh... and they also do some this is an aside but vm's don't work uh... we had a whole development environment based on developers having vm's that they did their work in it complete and utter crap do not do not use vm's for this use real hardware uh... qualified assignment uh... yeah we own okay so it's slow it was no matter how much resources you gave a vm for a developer to do their build uh... it was ten uh... it took one-tenth the time to do a build on a real hardware then it did on our best vm so i'm a developer just running bit-bake a no-op bit-bake command it took ten times as long and so on my real hardware i could do a build it uh... so we actually have some shared infrastructure now for real hardware developers have logins to a couple of beast machines and we do the builds that take twenty minutes on that machine and on our or vm it was taken like three hours to do it from scratch no cash build sorry i'm so okay i'll qualify cement some people can have uh... success of the m's we had some really smart people dedicated to doing vm's and they could never get it to be as as good as hardware and i saw a lot of head shaking here so seems to be a sense of it so if you want to know how to make vm's run really well i'll go talk to that guy uh... so okay sorry might have run out of time for my demo i have five minutes to do this demo and it's about five minute demo okay so uh... oh my gosh that's not going to work uh... fix the font size i guess okay what's the increased font size khaki command plus thank you not great but usually does my next box sorry uh... c okay resets and work that i okay so just to give an idea uh... setting up these mirrors just a quick and sorry i didn't ask can everybody see this relatively okay we have a mirror internal but for conference purposes because wife i sucks i have my own little uh... copy of pokey uh... so i'm i'm basically gonna set up a tree where i have a uh... a pokey and a pokey next i'm gonna call them pokey court crogoth and pokey morty so have a upstream copy here and we have a a very positive for you here and another very positive and then i'm creating a uh... check out of the pokey and then i'm gonna push uh... what this is the i think yes the question i'm pushing the crogoth branch in the upstream pokey into ralph fourteen g master of my very positive three so my bear my very positive three now has just that one branch and then do the same thing for with morty i call it pokey pokey next the group back in repositories i just named them after the release so pokey crogoth pokey morty uh... so we're gonna just switch the pointer of which repository we point at because it's because between the branches and pokey you can't pull between them so that's that uh... so i have a repository a repo i'll show you the manifest in a second but have a manifest that just checks out those two pokey repositories and i'll show you what that looks like after finishes i'm checking out so this is my manifest uh... here we have revision uh... we're checking out ralph fourteen g master and pokey crogoth and pokey morty so this get checked out into the pokey directory in the dot next pokey respectively and i have one minute so you take me at work a couple i can see the into this repository and you can see here i have dot next directory that'll have pokey and pokey in it i could do get get logged in both those directors and show you that they're uh... the different branches but i'm not gonna do that for time miss which the manifest to now let's say we got everything that done the way we want it to and now in the manifest on the switch pokey over to morty and then i'm gonna check that in and so now if i go back into my repo and i do a repo sync you'll see that switching it's switching my pokey crogoth over to pokey morty so you'll have to use your imagination for the rest of this but it's all fairly straightforward and said works for us uh... i think that's the end of my time uh... thank you guys