 Good evening. Now we are going to have a talk with Luciano Vecho in Spanish is something like Luciano beautiful Open S H debacle, thank you, sorry for my English Okay What everybody knows why you are here. I mean remember yesterday we see the problem related with openness of cell and Now this bof. It's what can we learn about this this debacle? Let's see I have some notes if you want to join me. This is the IP Thank you, and let's Go to this part of the talk yesterday. I will pass over it We will try to see what happened here the idea here is I'm not a really Devian the bell list reader. I mean I have Is things better to do in my with my time? so but Many people ask me Which are the the goals for devian to fix this bug in the future to fix this kind of issue in the future So that's why I propose the bof this bof, but what I want to say is I have Not really a deeply familiar with With some that sure Rhonda Yes Yeah, it's fine with it It's working for him you have the fire was sorry the output fire. Well, I'm pretty sure Hmm. So that's the part which I usually said in this talk a As you can see it there. It's my point of view, but I would like to Agree this point of view with you or most of you it's impossible to agree agree with all of you Of course, but with the most of you so When many people Complaints to devian about this flow I showed this this slices in order to discuss a Better way to approach the the problem We should notice that devian needs patches many people think that it's something wrong to patch software in the distribution But that's what our distribution is That's because sometimes they have different goals than Upstream for example in this case for devian is something important have a balcony clean system and not for open as a cell core team And in some case the communication with upstream is not so good In some case upstream is dead in some case upstream is hostage The problem is no so obvious. So it's not it's not enough with a see patches And of course, it's really impossible audit all the core in devian It's there is no way to do it by hand and that we need to find it an automatic way So we are looking away for do best software not to not a way to complain people That's something important in many first in the list We are looking for a way to okay We can do this and if something goes wrong we have we we can get something to blame We can get somebody to blame and that's not the point here. We need to find a way to make good software so This is a summarize of some list a Some threats in the devian the bell list I think the best issue here is improve the visibility That's was the the main goal. So that's why We are looking for a public BCS version control systems The new B3 format for our packages will will be more evident will make evident the the diversions is A wake for a standard the headers in the patches Will be a some something to go in order to get a patches dot devian dot org and Another another idea I think came from showy has It's managed the the divergencies as bugs Of course the solution or should be in the intersection of the sets a The technical problem sets the policy problems and the social problem if we combine all of that kind of solution will get the The solution for the future for this kind of loss so I made a little Some notes. I would like to emphasize What we did well in this situation we give a really good tool in the in the in the in the advisory moment to look for weak keys and that was a really really good situation and Administrator have an easy way to check her keys. For example, the tool was not perfect, but works in both the case a The the maintainer Follows the good practice. He discussed the bug in the BTS then he asked to the upstream and they he published the the changes in a public VCS But as some things that we need to improve The package in this case has not a devian dash package For me was a really something really difficult to find which line was the guilty of the problem if Debian patches exist for me have been more easy to find it Another problem is that that is only one maintainer in the practice way I mean in theory there are many maintainers, but only Do the the heavy shop? a The open as a cell package has and request for help open from from many years and it's still open So that's something to know Probably most of you didn't know this but when a few years ago that a few few days before the advisory The patch was a upload uploaded to seed Fixing the problem that was not something good because if somebody founds that difference can exploit the vulnerability before the advisory Converting this problem in a survey issue So that's something good if we can find a change a way to fix this too so about the The tracking diversity as bugs For me, it's a wonderful idea. I mean we have tagging in the BTS. We have an easy way to forward The bugs to the upstream we have records in about which mail address we send the Divergency We have a place to storage the debate if the patch have controversy a The the patches Are not really critical severity the in the in the maximum case the the the diversity can be important and With the old patches in the in the BTS should be an easy way to create a patches.debian.org Others ideas that I see in the mail are related with We tried to make a way to classify the packages In order of importance Many talks was about this try this intent of classification I think it's really difficult because it's really difficult to find a criteria and the human effort. It's huge Madoc Do you have a mic? Why Madoc have not a mic? I Don't know that much to say Well, this is Joey has this idea right tracking divergence from upstream as a bug Or maybe someone else has that idea as well. I just wanted to say that I think that's a gross hack because Divergence from upstream is not a bug yet the bug tracking system seems to be The tool that is well established in our workflows. So why don't we use it to also track? Well, the divergence that we have many concept. I mean a wish list is not a bug, too Right, and I mean and a request for adoption is not a bug in the sense of a mistake in a program No, I agree. We use BTS for many things right, but that's not necessarily something that is good That is not necessarily something we should continue doing that is not necessarily something that Shouldn't be unchanged forever I just look at this list and all I can think is version control system and well all I can think about then is VCS PKG right because that's exactly what we're trying to do And possibly even across distro. So maybe instead of you know, let's not go down that alley even further Let's not take our buck tracking system of an abuser even further. Let's do this differently Yeah, just to put the exact opposite task our bug tracker is not just a bug tracker We call it a bug tracker because that's what most things in it are but it's really an issue tracker It does far far more than just track bugs It's like a ticket system. Exactly. So While we call it bugs.devin.org It's much much more you could if it makes you feel better you can Replace everything. In fact, there is an option in the BTS right now to replace every instance of bug in it with issue Because people say oh god, this is not a bug So Yes, indeed. Yes, you can replace it with feature as well It's a global value that you can set for your own instance of the BTS so There's a lot of things that the BTS does for us automatically Okay, so Maddox is claiming that it's also not an issue, but I think it is it's an issue that anytime we Diverge from upstream. It's a case and I made it in the thread that we it's a huge thread that we had It's it's something that eventually should be resolved I mean if we if we if we have the need to make a diversion see It probably means in most of the case that something don't fix with us I mean, maybe it's failure like a system or something like that, but You that's another people here. Okay, Stefanos here We need a mic here. I just wanted to say that I don't stalking up there. Yes. I'm Antoine from kumbit I just want to say that I don't think it's really important the way we The way we track divergence from upstream. Where is the BTS or patches the demon or I don't I don't really care I think what's really important that there's there's some areas that are critical the Open instance a libraries the compiler I don't know the web browser. There are some really sensitive areas, but it's operating system and those those sectors should be specifically and targeted for peer review and security tracking and This is one of the main issues this issue has brought up and I think I think that people are going to watch open SSL and This throws much more from now in the security community, and I hope they will so I hope that such Problems are going to be detected much earlier in the future But I think we should I think that Debian project should take extra care now to ensure that those areas Are specifically monitored for security issues So you are in favor to make a sub set of packages like critical packages or something like that Yes, so so you mentioned tagging like a security. Yeah, so there should be a set of packages that are security critical Here I was talking about a security diversions is but I So I tried to make the exercise to to to Generate the criteria of which packages are more important, and it's really hard I mean we have a similar problem a few years ago Related with cron. I don't know sure if you remember, but that's a root execution and cron doesn't look like a security by package Yeah, what I mean What I tried to say it is okay, you include browsers you include compilers if you include so many set you You will cover the 80% of the Debian packages. It's my point of view, but Please the back lay or something else. I'm sorry. We have an issue here No, no debacle. Okay you So I agree actually with mother position and I find it interesting that during your talk You're doing your introduction to this both. Yeah said something like people say we should not patch and you You actually even answer it with that objection saying this is what distribution are about and this is true And not all the changes we have Issue bugs sometime are just meant to stay there in Debian with agreement with upstream. Okay, so Given that not all of them need to be fixed not all of them should be tracking our bug tracking system or issue tracking system or whatever Yeah Yeah, in fact, we don't need to look for the upstream agree in all the case many in some case upstream is there But it's important if you we put in a in a single point of looking in the web, so Maybe upstream doesn't look it, but another can look it But having purchased the banner and it's not the point about putting everything in the BTS because we a lot of time We just look for a place where to put stuff We have the BTS which is great and we just want to use it But I mean you said something like if we use the BTS then it would be easy to create patches the bianorg But the goal is creating patches the bianorg not putting everything in the useful way I mean for example patches Ubuntu It's just a file off index off of patches So we need a place where we can discuss the patches. I mean really fix in the BTS But okay, let's continue the discussion. Yeah, what I wanted to say is that you can't always Apply the same rules on packages. So I would agree with your listing for critical packages But if you wanted to apply to let's say of an opposite org You at least would need to find 400 bucks I'm not sure if I can listen to you If you want to apply those rules to all the packages in the end then you would Have packages which get 400 important box more. I Know some packages for somebody can't reveal me what he said Yeah, well if You apply those rules you are outlined in the If you want to handle the versions from upstream as a bug Yeah, if you wanted what to handle every every patch as a bug Then you have some packages in there be and where you need to find 400 bucks And that's why this is part of the problem. I don't think this is problem because There was a well For the package I meant there was an unofficial version with the patches included so I count this one as a upstream, but I What I mean is I have it doesn't scale for every package in there, okay I'm so here I Think that it's important that to remember that we survived for 15 years without something like that Sure, and we I don't think that need to change our workflows fundamentally We just need to have to solve that problem in a lightweight way because if we want to file one bug For each divergence that you are from because you can't just file it for important divisions because that could I I We won't find a quite criteria for Important divergence from up from upstream you have to file a bug for each Divergence if you want to do that. Yeah, that's just a lot a lot of work for I mean most of the but most of the patch won't be interesting at all and are just minor stuff So we have to find the same a simple solution that is easy from the maintenance point of view And that really serves the problem that we want to solve and I think that the problem that we want to solve is not about Security it's about being good citizens in the free software community Exposing what we change what we improved in the package so that upstream can easily pick it up because Upstreams are looking for that and they really would like to have a simple way to see what every distro changes and if in Debian they have to look at At the bts and go through all the bugs that we have just to find a few ones That are about patches. I don't think that upstream will be appear about that and So there's There's the idea of having some common website like VCS pick a gel whatever else where every distro Can push their patches and people can upstream can just look at it I think that some people in Ubuntu already started working on something like that I'm not sure if it's enough. We don't know it's not launchpad It's not actually I think it's a clinical employee who did that but on its free time It's not an official project. I think but maybe a judge can clarify. I don't know if he's here Well, but we our part of the problem is Exposing our patches in an easy way. So Some so a script elsewhere can pick them up easily and I think that patches that they beyond that org would really Fit that clear criteria and about the point of having a place for discussion If the patch fixes fixes a bug you can discuss the patch in the bug that was fixed See if if the patch There's no need to open a different bug just to discuss the patch that was introduced Because the patch fixes normally fixes something that was documented already Okay, no It's definitely want to talk to yeah, if I could just interject Maybe what we need then is a combination of two approaches one We need to use bugs.debian.org for things that are bugs that we have fixed by diversions from upstream Or specific patches because most of the cases that we're going to talk about there's going to be a bug filed Against bugs.debian.org about the actual issue. We will then go ahead make whatever change is necessary to fix that bug We will attach the patch that's fixed that bug specifically perhaps using deb commit tag that bug Divergence it'll get closed in the normal fashion then a Patches.debian.org website or something that somebody writes will go through Find bugs that are still tagged as diverging from upstream will pull them and along with any Specific patches that are not yet integrated upstream perhaps automatically perhaps by maintainer submitting when they do an upload or whatever That works and so patches.debian.org becomes the union of the set of bugs that are in bugs.debian.org and Divergences that are minor that weren't that didn't necessitate a bug to bugs.debian.org I think it's important that whatever we do decide to do leverages the Here I go into market ease but leverages the power of bugs.debian.org and to avoid Duplicating work since maintainers have already discussed the bug there that in most cases there's already the patch there That all information should be pulled in as well Can I say some but it's low. Sorry I I Feel like we may be looking at this the wrong way around and it's very difficult to answer it done in This because I know how much time and effort you've been putting into bugs.debian.org And I don't want to discredit this at all But for some reason I have the feeling that we're doing this the wrong way around rather than trying to Integrate version control systems with a bug tracker by having some sort of specially crafted commit messages that then go to the bug tracker Or even send the patches there which are going to be just a linear series of patches You won't be able to like diff between any two of the patches easily I think we should look at tracking bugs in version control and and integrate that way That's that's sort if you remember this thread that Joey put up about like tracking Upstream as a divergence of an upstream that was one of the points I made and actually there was not very much that was responded in terms of it But I'd like to think about it in this way and maybe you have something to say to that or someone else Yeah, yeah so there's a long-standing problem of dealing with Distributed bug tracking which is really tied in with tracking bugs in vcs's and unfortunately that's still a problem that's unsolved So while I agree that Perhaps it may not be optimal and I know that our current system is not optimal We at some point need to stand back and go for a system that is good enough to start with This is a problem that we have today and we need to come to a solution that at least Starts to solve a set of the problems even if it's not optimal. It's what we've got now So we should start using it to do the things that we can do I mean, there's nothing stopping us now from creating a package.debian.org that is at least Semi-usable using the information that already exists in the BTS today without any extra work being done by anybody So I mean while going forward I would definitely look for people who are willing to spend the time to do something It's better as it stands now. This is what we've got. So we I mean we can make it Do stuff useful just with the information today Probably first one we need to Force our developers to make a devian-patches and not a huge diff or Soundfilter. I mean In not all packages have an easy way to put patches in a insolid way and in a good way Sorry Even just dev commit or something would do that simply even for pack people who don't separate out their packages currently Because we've used dev commit you can it knows which bug you fixed Generates the change log and it could easily be modified to also send the patch or something like that So I mean, it's not like it's a big deal to just attach a patch I have looking for source of some packages where the commits are really messy, but yeah It's it's a it's a special it's a special I mean continue maybe it's just something that we need to Bring together more so that more people aware that they should try to make patches as clean as possible Yeah, so it seems that the ideas spin around some rearrangement of the information and While this will definitely help to identify potentially issues like that. I don't think it's Getting us anywhere closer from to preventing them in the future, right? So what I think is would be a good idea. I mean the obvious Idea, which I don't think sounded before is some kind of code review right It's it's it's horrible. It's hard and The the usual way the corporate the the corporate world does code reviews will probably not work However, I could easily imagine so that the idea sounded about Identifying security critical packages, right? I Would for example could imagine creating a new mailing list which would I The act as some kind of technical peer reviewing body Which maintainers could use of their own accord or In an extreme case that all the commits to the repositories of these security critical packages would just go to this list The idea is just that I'm pretty sure there would be people who are interested in looking from the security point of view at all these commits and just having this More eyes look over it would actually have a better potential to prevent such issues what we have a devian audit I think it's that but we have it. I mean have as a web page. That is a web page for devian audit Do you know how devian audit? I don't I? Only know the page It's death. Yeah, and that's because that's not many people who wants to seek order in the weekends that This this kind of law at the open a cell floor was a really serious of of Mistakes and was really something unlucky if we want if we Probably in the future will be really hard to get another one of these ones If we only just touch one of the part of that series of unfortunate events a That's I think that's will be enough to to try to prevent this kind of the problem in the future Audit code is I mean is inhuman. I mean That's Well, that's that that's why I'm saying that post fact post factum audit is hard and it's hard to find people but if you if you get people to look through the Commits as they come in and at least say okay I think it's fishy. I think you need to check more on this and things like that There are people with different level of paranoia, you know and in this case I think it would be good if people would just raise red flags and it would be a little bit more Work for maintainer and everybody to figure it out But I think for a closed set of security critical pack packages It would be really beneficial But even even for do that we need an easy way to discuss patch in a forum way So that's what I'm with that's what we are looking for. Yeah a mailing list. Sorry a mailing list Well, I'm not sure is the best way, but okay Good idea. I just want to It's working. I just want to reinforce on what this guy was saying Someone was I don't know his name and I'm sorry. I'm Yuri. Hi Someone was mentioning that we survived for 15 years and that we're basically okay. I I don't agree with that. I think that Debian took a serious hit a serious credibility hit with that vulnerability and that affected the project as a whole so Yeah, we survived But I don't want to go through this ever again and I'm pretty sure that nobody wants to do this ever again So I do think we need to change The processes and I'd say we I'm not even part of the demon project But anyways, I think the demon project needs to change those processes to make sure that this Never happens again or at least try to make it never happen again So I think that did the mailing list idea is a good idea I think that Isolating if it's if it's necessary because there's too much information passing by just isolate I don't know crazy like SSL SSH and the current old patches Okay, the current on on on on the mailing list. Well, I don't know 10 packages Okay, how many like that critical packages are there like open like open SSL, right? So Well, I don't I don't agree So I think there should be a mailing list out there that people are free to subscribe to that just lists all those Commits all those patches that come true. We are working on deviant. We are working big with a baby I don't know Miriam a train to make few measures Numbers in order to get a Way to score a package But it's it's really hard, but please showing us it's really really be careful, but sure. Yeah, pray to do that regarding so I really think that Any program that takes any input that might be controlled By interested person is security important so, yeah, I don't think identifying I don't think that identifying Subset of security important or security critical packages will work and the other thing Wanted to say is that maybe a middle maybe a middle step in the direction of code with you is a certain kind of team maintenance With a commits A mailing list, so I don't know how many people do that But but for a few of the teams where I am I do read the commits meaning list some weeks I'm too busy, and I don't read everything in it, but I try to get a view of Of every commit that happens to the packages of the team that I'm interested in And yes, sometimes I just see a book and I correct it like that. So If one team that looks at all commits of all security critical packages Won't work. Maybe team maintenance of packages will be a middle step that might work Which reading the commits by other members. Let's go over to him in order to finish this classification You want to say something about classification of packages I Mean just for finish the issue for finishing this issue. He was he was mentioning I think it's a Well, it's important not to Not not to think as a package as a security related. I mean like opposing to what you just said most patches are Well, you cannot see You cannot just from looking at the patch. You do not see the context I mean if you look at the at the at the patch in question that was found there You wouldn't understand just from looking at a few lines. It was removing an important call In fact, if it were so obvious, it wouldn't have been in in the first time in the first place. So Well, just sending them to a mailing list Would make no no sense because the the people who are Following the list may just see yet another patch yet another patch and the not to not even try to understand each of them While if we're doing some kind of audit be it security minded or be it any other other thing having each patch set as an issue as a something that Stands out somehow either as a bog or a feature of issues or whatever Can bring more attention to the QA question Okay, I just I just want to say that I Disagreed that all code can't be audited other projects are actively Monitoring all code. They put in the open BSD project is auditing everything the free BSD project Has a mailing list where all we show in the world For I'm just let me finish open BSD is monitoring all the core And actively auditing all the core the free BSD project has a mailing list where all the commits To the core and also to the port system are sent to so there are more eyeballs on that code than on the demon patches Okay, so I I'm not saying they audit all the port system in that it's it's it's flawless Okay, that's not what I'm saying. I'm just saying that right now There is no place where there is all those patches coming in when there's a new patch on open SSL You can be sure as hell that people are going to look at it now even if it looks like Irrelevant a little common thing people are going to look at it now And if there is no place to take a look at all those patches that come into Debian then I think it's a problem Okay, my dog. I've just can can you hear me? Yeah, I thought enough. All right. I've just heard a couple of things in the last ten minutes One of them was that we've been going fine for the last 15 years But we've also never been as big as we are currently in the 15 years And if you define success correctly, then we're gonna grow right so we need to be able to scale Also, we can't really be compared to another project per se like free BSD because we're bigger We don't have enough eyeballs to actually look at all of this So and then there were two other things that I heard which was let's create two classes of packages One of them being the security critical ones and one of them being the less security critical ones and for the security critical ones Hey, let's push all the patches out to a common place And you know as long as everybody is reading and we're not on vacation and we actually care We will find every single bug. I think that's completely the wrong way I agree that we should never have something like the open SSL debacle ever again But if we actually if we decide that this is something we need to guard against then the only way to do that is not Post-mortem, but pre-mortem. We need to be working In advance and we need to be approving rather than checking patches And then there's actually a something that I've been meaning to do for a very long time Which is something that I call upload certificates These upload certificates are basically certain checks that you have to run Which are defined for each package. So you could have a larger number of checks for libc or open SSL Then you could have for like a small package that nobody uses But these would include things like lincean have I built it from source have three Debian developers looked at it Has this gone through a security audit and this kind of stuff and unless this Certificate is issued. The reason why I haven't done it is because I don't know how to cryptographically do it properly Unless these things are done and all the certificates have been issued for this Package, it's just not going to get uploaded period or maybe even the patch doesn't make it into the version control system And now if you look at any company that does a lot of software engineering and that uses version control in their Workflows in a professional way, then you will see that every single commit has to be approved by other people Perforce is a very good example of that. It has all of that built in But that's what companies like Google and Microsoft and so on they all do exactly that The commits are approved before they go into the code base and the code base is therefore guaranteed to be cleaner So I think we need to do something before not after Way to checks Patches or checks the urgency or checks New uploads automatically Check check the stuff that makes the upload happen check the stuff that comes in the components of the upload Don't check the upload after it happened It's just like your example yesterday from the SSL packages like commit sent all my payment details And then come back and say oh oops the certificate is wrong. No, that's too late You know you want to have it done before sure, but but the most major flows are not so easy to check I mean we need humans for do that kind of types and this is a really huge I think Yeah, hold your place what I mean. Yeah, I think Martin is right that we need to do more checks before Allowing the package in but I think that it will never prevent Errors that will always be Floors which will you not detect it by audits? And I think we should limit the security support to a subset of packages in Debbie and not to only Security related packages, but also KDE and GNOME, which will never be audited completely So that we maybe only support three or five thousand packages For security support so that the security team can cope with the existing Issues there are still many many issues in testing and stable which are not fixed And I think we should all need also need to do this so I'm in favor of limiting this the security support scope It's not about a day. I mean the most of the problems are related. We are with a huge archive I mean many distribution does things like that one Yeah, yeah, one of the problems to though with stopping stuff before I think it's not It's working. They make it is one of the problems with requiring that much documentation though is purely scaling is Holds was talking about. I mean big companies like that are maybe releasing One product or two products in a team whereas we have Already so many RC bugs that we have a hard time scaling to the number of packages that we have Even for security critical packages the number of people that you'd have to pull in before an upload that would require that type of checking I mean it would be prohibitive. I can't imagine us I mean I I would be really happy if it were to happen, but I can't imagine a scaling to that I mean perhaps before Investing too much work should try for a couple of packages to do this Because I'm I almost guarantee that it's not going to work after you know a month so Just sort of to you know, give it a try run before even really bothering to talk about it much more Comment we have time. I mean you can be short, but please go on Yeah, so I also have my doubts that such pre checks will work so my idea about checking the commits to SVM kind of The idea is that it will preclude packages going into the archive But I think that the common corporate scheme will just not work because you know in corporate scheme You can tell people first of all you have a few people working on a project the ones which do code reviews and then you can tell people you know do code reviews are you are fired and and Not that it happens But in Debian it it just will not work it it people people will you know the more barriers you set is The less motivated the maintainers will be and things like that too. I also would like to comment on everybody saying you know it will not work or it's too complicated or Mailing list will be inefficient, you know Something is better than nothing. Yeah, sure. So that's what it boils down to yeah, we can we can kind of say bad things about all these proposals, but They are actually trying to achieve something and we can try things and see if they work out or not and Work from there was on again Yeah To to what Don was saying earlier Well, I was comparing us to companies and he was saying well these companies have dedicated teams to do releases and release only every now And then I have that feeling that we're maybe in Debian trying to do two different things Right, we're trying to push out new versions of our software with regular intervals at the same time We are trying to Harvest the power of a volunteer team to produce secure software now. I think we have to choose either one of those I don't think that saying we can't get this done Because we are only volunteers and because we are in a tight time schedule is Going to help us anything. So it's either Doing what open BSD does which is basically to secure first release afterwards or it's release every 18 months and and Try to do our best, but if we try to do our best, we will have a problem like this again It's human it happens To make a story 10. Let's me We're gonna have a problem like that again no matter what we do even if we do have the most rigorous code Checking in the world problems like this are going to happen. It's the nature of human written software The effect is probably the nature of all software. So Mozilla is a fairly large Project that I think nowadays Has mostly Volunteers and they have code review and a super review On the hand when I file a book In Mozilla upstream usually It runs for a few years, but That's probably because it didn't pass the review. That's probably because it didn't pass the review Yeah Just a new topic which have been neglected as far which is patch documentation So basically in the open cell case, it was a just the patch was just in the big diff gz Right it's wanting. It was not in the patches. So this is something which should be Labeled as bad practice in all our packages and on that side. I feel a relatively safe with the new DPKG versus three package format because as far as I understand it will be impossible to directly change stuff To the package without having something in the beyond patches, right? That's what I answered to So that's the first point, but this still does not enforce having documentation in all patches and I think that Just after Lintian started bothering about the Debian patches, which were not documented people started documenting them So this is something which we should push more. So just Saying if you have a patches in Debian patches, which will become mandatory from DPKG versus three Then you should document it with the two lines explaining what the patch does. So this is another point and Okay, let's see. I was listening about the new version from many time ago I agree with the new bit the new bit free version with this will be easier to do But what about what about make Debian patches now? What Dan says we need you to make something now I mean many packages use these kind of things and the huge diff and Try to enforce them to to migrate to a Debian patches Right now They always has a bit of inertia So having DPKG versus three meant to be Lenny plus one is I think as quick as we can get But another comment I forgot to mention was about code review I frankly don't believe too much in code review But it is interesting that right now we have no way no centralized place where we can monitor all our commit messages So I mean if people want to do that Right now we are making a really hard to do that. So it will be interesting to find out a way where we can just Join together all the stream of commits we have so people can look at it I will never subscribe to that mailing list, but it would be interesting to one Thing I think it's really important that we separate patches that we have comments were Of what the patch does what I think we can take from the kernel is have the signed off by Of every patch so you can see who created it what was done I think it's also really good practice to also even if you don't want the upstream to have your patch to at least talk to Them to say hey look, this is what we're doing what you think about it, which in this case was what was done But then you can have and see tracking and it's it's not to blame. It's just to see You know for yourself what I've been done and then check like Mad Dog was suggesting are really easy You just look for two sign of buys when you get a packaging and you know that somebody has looked at it Like whether it's the upstream or anyone I'm not I'm not sure sign of buy really applies to Debian It works for the kernel and it's required for the kernel because they don't have change logs, but we do And I think you should already document everything in the change log anyway So adding China signs off buys and truly going to add much there Well, that's about them. Yeah, so you're saying that there's no way to to cross-reference the patch with the change log But I think that's about them It should be there in the change look the change looks to explain what? Was changed so if you add a patch and you don't document that patch in a change like you're doing something you should be doing In Most of the solutions we need to make a huge effort in the beginning But with an unstable situation that that's not to be more something Something really hard. I mean the we have a lot of patch now But if we document all our patches now then the the line will be stable I mean that has nothing to do with the huge big effort in the beginning Another comment so just like summarizing Looks like we need a place to to put our patches in a unique way I am not sure if you are agreed with this bts diversion see issue Of course needs more discussion in many quick in many cases the discussion in the mailing list are endless and It's for me I have a problem with Debbie and the bell I don't know nothing ends in a Practical way, but Sorry, you have Debbie. I need us Sorry, maybe you could do a quick poll in this room about the divisions from some other back But it's difficult to see if the people thinking that it's a good idea our majority or minority Actually, I'm not sure if I understand you but you want to a quick poll in this room as Paul. Yeah, just ask Oh a boat. Yeah Okay, just a poll to have an idea hands up to track a Diversion see like a bug ups the hands up for don't try to a Diversion see like a bug So what's your proposal I Just wanted to say that madam Martin was saying the hands up for tracking it was a package see SVM or CVS Vcs anything like that track a diversion as a patch manage the patch Itself, which is the diversion and don't keep it stored somewhere with as a bug But that that was what I was going to say before that Currently there's no lintian warning if The files are modified outside Debian are modified without a patches dear I think this is tracking with the this the lintian warning. What else do you want a? Lintian I was one error sorry to have one place where these patches are accessible and not necessarily one Place only like patches that they be in that org which is a great idea But it might be difficult to pull in those patches especially if you want to track patches if you want to have a commit ID but have a Way in which it is easy for everyone upstream other distros ourselves our QA and our security team to get at Patches and look at them. So a standard way of accessing them But yeah, that that's the way to put the patches into there in Debian patches, then you can then you can You don't have a microphone The question was from from Rhonda whether that doesn't just mean that I want an RSS feed for patches that they be and not Oregon I Don't because you will possibly have a patch that is false. That is wrong So there your RSS feed goes out to everyone and the patch People look at it and the next day you decide. Oh, there was actually a typo in there So I'm going to change it now you what are you going to do on on patches that? Debian.org are you going to have a new patch that has all the old changes? It's basically between the new tip and the the the master or are you going to have an additional patch that? That describes only the changes you made since yesterday and once you have that Are you still going to be able to have one location where you can find the current most up-to-date? Patch that applies and then possibly be able to look at the history of this patch I mean that this is it seems to me that what we're trying to do is exactly that it's changing its tracking patches, but If there's this lintian warning we have the send error We have the central place to look them up lintian Debian org and then you can see in the packages that they which VCS they use and you see the patches and for each upload Where you change the patches you change the VCS thing so and currently it doesn't there's even not I'm not sure if there's even a record recommendation to use VCS for packaging an official recommendation, so This is the next step to do that and I don't see What you really want in the end? This is why why patches Debian org is not enough if that is created every day from sit The problem about a purchase over patches when you want to patch a patch or something like that I mean that in that case they the the the patch as a bug doesn't work and it looks like Fixed me. Yeah, the way that I think patches.debian.org could work Because I do think it's a good idea to single point of entry don't get me wrong But it should actually delegate to the information in the version control system or to some sort of Unpacked Debian patches directory for all the Debian packages that don't use a version control system I'll all I want I don't want patches.debian.org to be a dump of patches or to be a mailing list Exploder or rss feed generator that just dumps patches it needs to be a way for you to get patches and to Analyze patches and to analyze their history and to look at Basically what the version control systems do so patches.debian.org is what we feed out to everyone every upstream every other Distribution knows patches.debian.org slash mutt is where I can get all the patches that Debian has applied to mutt The question is how is the back end then organized and all I'm saying is let's do that proper Rather than then patches start some other distribution dot com That will not work not every maintainer will want to use some central version control system There will be spread around and the the best we have is that the pts shows which we see which we see as is in use Would you make please you don't need it. It's really easy to work out the difference between a patch of between two uploads It's really easy to do that That's easy, but you still need you still need to have the two versions so we know we Need snapshot the domain at all I think but maybe the the VCA the BS the VCS Approach it's probably more More a bar cative, but it's more complex. I can't and can't be applied at it now In the BTS way we can start tomorrow We need to generate the way to to create the VCS Way to manage our patch instead of just uploaded to the BTS You can take all your patches and put them into a VCS and make patches to devian.org that VCS exported So then you have tracking you have everything you need Times up Sorry good times up