 Hello, everybody. This talk is going to be held by Steve Langechak. He's going to talk about the PAM off update. Thank you. He's been a development developer for like eight years and he's the maintainer of this project of the PAM off update and enjoy his talk. In case you have any questions later concerning this talk, please make sure you use a microphone. Thanks. Enjoy. Well, thank you. So I'm here to talk today about PAM off update, which is a fun little project that's recently been introduced into Debian squeeze. Who here already knows what PAM off update is? A certain number of people. How many people have had it break their system? Too many. You don't count. You were using it in a bun too. And Madduck, I don't believe you. So what is PAM off update? Short description. Easy way to make slides just stealing from the man page. It manages PAM configuration using packaged profiles, which is a fancy way of saying that at long last, we have a solution in Debian that lets PAM modules auto configure themselves when you install them, which is really, really nice. People have wanted this for a long time and we finally have it now. So yeah, automatically enabling PAM modules when a package is installed. It comes with a debconf based interface. We're using the wonderful debconf work that we have that's common to our packaging system and that lots of our maintainer scripts use. PAM off update is one of these funny standalone programs, which also uses debconf. And it provides this debconf interface that lets admins enable and disable particular PAM modules overriding the defaults. And this idea is something that we've been kicking around for a long time. Ever since we split, et cetera, PAMD into having these common-auth, common-password files, there was always this idea in the back of our minds that we would have some way to auto configure modules and have it all be nice, neat and clean and magical. But it's a, yeah, the idea has been around for about six years. And it finally came to fruition with a prototype that landed in Ubuntu 8.10. Unfortunately, due to the timing, the development was happening on this right about the time that Lenny was going into freeze, so there was no way to sensibly introduce it into Lenny. Instead, it landed as soon as Squeeze opened this spring, early this spring, at which point it apparently broke a couple of people's systems. So the first point, the first thing I want to talk about is how you actually use PAM off update from a perspective of a packager. And basically it's three simple steps. Eventually I'd like to have a Dev Helper tool that will do all this automatically for you the same way everything is done automatically for you these days. But for the time being, it's simple enough that I haven't gone to the effort of writing the Perl script because these are the simple steps to do it. You install a profile under this directory. So ship this in your package. Here's an example for the Kerberos 5 package. This is actually taken from the LibPam Kerber 5 package in Debian. And it shows you the syntax. This is a very simple declarative syntax. Well, simple. But it's a declarative format. So there's no Turing complete zaniness involved here. You don't have to deal with the crazy things that maintainers come up with using scripting languages if left to their own devices. And you see here, you give it a name which is actually going to be the simple, the user readable name that's going to be displayed in the Debian Comp interface. Default, yes, means it's turned on by default. It has a priority which tells PanWolf Update what order to put them together in the config when it puts it together. We declare conflicts here which says that if you also have the Kerberos 5-OpenAFS profile available you can only pick one or the other. Auth type primary, I'll explain a little bit more about that. You see here some lines which, if you've ever looked at a Pam config, you can probably gather that those are templates that are used to generate the actual Pam config. And then you also have sections for both auth, account, password, session, the four major groups within Pam configuration. So put one of those together. Put together a post-inst which this is the post-inst. This is actually literally the post-inst for the LibPam Kerb 5 package as those five lines to which are white space. The pre-RM is somewhat amended here from the actual package because Russ has a 10-line block of comments in there. So to fit it on the screen I only gave you the functional bits. So basically we have a pre-RM that just on removal tells it that, yeah, we want to remove it again. And I'm going to go through these slides fairly quickly. They are all linked from the talk profile in Penta. So if you want to follow along with the slides later at any point those are available on the web already. And Profit, that's all there is to it. That's all it takes from a maintainer to plug in their Pam module so that it can be auto-configured and exposed in the interface so that users can enable or disable it according to their preferences. Some of the features that Pam Off Update introduces, any Pam module package can provide zero or more profiles. A Pam module package doesn't have to do this. It's nice to do it for a number of use cases. There are a lot of uses that we're putting this to already. Among the packages that are already deploying this in unstable at least I don't know if they've reached testing it. We've got LibPam modules itself for the Pam Unix stuff. We've got Pam Cracklib, which if you've ever looked at the old Pam configs there were all these comments showing how to uncomment things to hook into Cracklib which we don't have installed as part of the base because of the Cracklib library dependency itself. Well, now you just install the Pam Cracklib package and it's automatically configured for you, which is great. So we've got Pam Unix, Pam Cracklib is doing it, Pam Curb 5. There's a Pam LDAP profile which I guess I'm not sure, 100% sure that's merged in Debian yet. I know it's available in Ubuntu. SMB password for password synchronization with Samba. So auto migration of passwords to Samba is all set up already. Windbind is missing yet. That's on my to-do list. All those Pam modules, whatever you want to configure authentication for it's really straightforward to do this. The other thing is that you can have a package that just ships your profile. It's one of your custom packages for your site-specific authentication configuration. Create your profile, put it in a package, set the dependencies right on the other module packages and you're set. Declare your conflicts with whatever the Pam module provided profile is and you can just override it just by doing a dependency and you're good. We have support in Pam off update for specifying profiles of two kinds. They can specify additional requirements for authentication, authorization, those kinds of things or alternative requirements. So you can have both a system which requires, you know, you can say user must enter a password and provide a fingerprint in order to authenticate or a thumbprint type thing. Or you can say user can do a password using one of three different authentication stores. You can, you know, alternatives being local Unix authentication, LDAP, Kerberos, Active Directory authentication, whatever you want it to be. And so there's possibilities of both making those alternatives or making them additional requirements, which is very fundamental to this. You kind of can't do everything you need to do without that flexibility. And that actually comes back to, let's go back to the earlier slide here, where we say off type primary versus account type additional. So off type primary says this is a primary means of authentication. So it provides an alternative for your primary authentication, whereas account type additional imposes additional authorization constraints on the logins. So that's what that's used for. And as I mentioned earlier, profiles can also declare they're mutually exclusive with one another, just using conflicts. I, you know, reused a bit of the terminology we're all familiar with from packaging. It's not very original in that regard. Other features, so it basically lets you specify, jump to the end of the section. I don't know who here does PAM stack configurations or not. The original PAM spec from Sun is fairly linear. Linux PAM, which is the implementation we use in Debian and most other Linux distributions also use, extended the syntax where you can say on this return code from the module, jump ahead this many modules or all this complexity. So we have that capability here as well where you can say, instead of saying jump ahead two modules or jump ahead three or one or whatever, we use this end token, which allows you to specify, jump to the end of this section of the auto-generated config so that you don't have to know how many other modules there are in the stack. PAM off update will figure that out for you. And another key feature is that it recognizes that PAM modules have to behave differently depending on where they actually are in the stack. So this is one of the things that you can't just simply say, I want to... So if you've got multiple authentication modules like Unix and Kerber 5 and LDAP all stack together, you don't want to be prompting three times for passwords. Well, the modules need to know whether or not to prompt based on where they are in the stack. So what we've done here is it supports combining forms. Basically, it lets you specify your default line that you're going to include, or lines, because you can have multiple lines within a config, and then also specify combining forms. So the inspiration for this actually came from the scripts used in Arabic and Hebrew where they have this notion that glyphs change depending on where they are in the sentence. And so the terminology here for initial, final, medial is very linguistic. But basically it lets you override the behavior of the module profile based on where it's going to line up in that stack. And so that way you can have the insurance that the first module in your stack always prompts for the password and then the one stacked after it know to use that password instead of reprompting. So you get much cleaner user experience actually using the system. And again, the default, yes, default, no. The profiles declare whether or not they're enabled by default. So you can get same defaults without having to do any prompting when the user installs the package. So yeah, how many people here run debconf with the default priority of high? And how many people are nitpickers who run it with a lower priority because they want to see everything? Well, you'll get prompted. You ask for it, you've got it. Your choice. But at the default high priority, there's no reason to prompt for it. So we just, you know, whatever those defaults are that are provided by the package. If the package maintainer has done their job, you get something out the other end that works right when you choose to install the PAM module and you never have to see any of these debconf prompts at all. Now you can go back later and just run the PAM off update command by hand and tweak everything. Did I hit another button when I wasn't looking? Yeah, all right. But the maintainer scripts call the PAM off update. You install the modules and here's an output. This is an auto-generated config, a real example from a system that has a couple of extra modules installed. I've got libpam curve five installed and I've got libpam SMB pass installed. So you get this output where on authentication it will proceed to try Kerberos five first for any user with a UID of 1,000 or above, which in Debian means all non-system users. And then if that succeeds, it skips the next two modules, gets down to here. If it fails, it falls through to the PAM Unix and tries the first password again, tries to use the same password that the user entered the first time to authenticate against the local Unix database. Now, we use try-first-pass rather than... No, this is authentication. So try-first-pass is the only option. So this means that if PAM Unix says, oh, that's the wrong password, it will prompt again for the user to try re-entering again. Use-first-pass is actually only available in the password stack. Well, okay. So Walter is saying that there is a use-first-pass option for PAM Unix on the authentication stack as well. So I'm probably just misremembering, and there is another option. We do try-first-pass to ensure that the user does have the opportunity to re-enter the password as needed. And then once we're all done, once we've got a successful authentication from one of these two modules, we jump down here, PAM permit. This is the module that actually sets our return code for the stack. And then we also have an additional module here, one of these off-type additional, which will do the PAM SMB pass migrate, which does this nifty little evil hack where it takes the user's password and creates a password entry for them in the SMB pass database used for Samba authentication. Since Windows negotiates passwords in a way that you cannot extract the necessary information out of MD5 standard Unix password files, we have a separate password store for that. And this will auto-populate it as needed. So you just install that module and you gradually become a fully functional Windows file server that way. So the actual implementation is it's less than 700 lines of Perl. Actually, I counted 600 lines of real Perl and 77 lines of comments. So it's a pretty, pretty small implementation for what it does. It relies heavily on DebConf to do a lot of the heavy lifting. I would have loved to have implemented this in Python, to be honest, I figured a few people might frown at me if Python became transitively essential on Debian. So I gave that a pass and instead I went ahead and implemented Perl. I did think in Python while I was writing it, but if you find the Perl strange, that's probably why. And about a third of that code is actually it's code that's just there to cope with all the things that users might do to edit their files by hand. The idea is that policy does say if the user changes the file you're supposed to respect those local changes. This actually does that. About 200 lines of code dedicated just to that within this config parser, but if a user goes in and just edits the config and adds extra module options at the end, we'll keep track of those. We'll make sure they get carried over when an upgrade happens or anything. So it's fairly robust and I'm very proud that we complied with policy on that because there are many examples of scripts out there that don't completely implement that requirement of policy and I encourage everyone to do that whenever they're editing configuration files because it's a very useful feature of Debian. Here's a peek at some of the code. You see we're just including debconf here. These are a couple of debconf operations. I don't know if you've never written debconf code in Perl, basically you get flat namespace for your various functions. So it can be a little bit opaque if you're not familiar with the API and you're trying to look at it. The things that you see here on the function names that you're like what is that that's not a Perl function? It's because it's a debconf function. We're reading in these configs. We have a function here to parse them out and throw the profiles into a nice little hash for us. Then we use the Xload template file extension of debconf which is a beautiful little thing that debconf and cdebconf both now support which allows scripts that are not maintainer scripts to force the debconf database to load in this template file because debconf being a cache it's not required to be there if you don't do this. So to ensure we always have the current version of those templates we call this function here. Then we do a whole bunch of sorting and mapping and grepping and yeah, it was a lot of fun. I'm not going to go line by line. If anybody has questions about the code later I'm not going to go through that in any detail right now. So why did it take us so long to get here? I mentioned this is an idea that we had six years ago about what we wanted to do with it. Now part of it was I spent three years as a release manager which means I didn't have any time to write any code. But you know the inspiration for this really came from Red Hat having a tool similar to this a full decade ago where you when you set up a Red Hat system you had AuthConfig which would prompt you do you want LDAP or do you want Kerberos or do you want Unix authentication or NIS or those kinds of things. But I wasn't particularly impressed with the implementation of it and I felt that Debian needed something better. Perfect being the enemy of the good or what have you that meant we had nothing for six years until we could do it right. So yeah it was six months of thinking about it followed by about two months of actual development once the opportunity arose to actually do it. My question to the audience is can we narrow that six year thinking about it? What can we do to be more active in Debian about making these things happen that we all know there's something that needs to get done but it just doesn't happen. And a lot of that I think comes down to mailing lists and we have a broad consensus about the idea that something needs to happen and something's a good idea but then we get bogged down in the details. These are some examples I came up with a little bit of a brainstorming in the Hack Lab this morning about things that people think are a good idea but we just don't actually make it to the implementation very quickly because we get bogged down in the details. Now in the case of PAMOF update I had the advantage of being it was my idea and it was my package so I wasn't actually dependent on external consensus to implement that so it was mostly a question of having the time to work on it and I'm very grateful to Canonical, my employer for letting me work on that and we were able to contribute that back to Debian. Like I said, Ubuntu got it first simply because of the timing of the Lenny freeze but as soon as it was feasible we got that right into Debian and I'm pleased with the results in spite of a really critical bug here and there. Nothing major, just nothing major but I want to open the question up to you guys and hear your feedback about how we can do better about getting things to the implementation. Is there a microphone for Colin here? One too, one too. First an observation, committees suck at deciding on details and the only way you're going to deal with the problem you mentioned of implementations lagging way behind the design is let somebody just get on with it and stop. I think we do a big second guessing problem as a community as a whole. The second thing I wanted to ask was a query about what users, sorry, not users packages that are PAM consumers I'm wearing my OpenS search maintainer hat. Is there anything that they should be doing better to make use of PAM auth updates? A lot of those modules ship configuration files that are full of comments about all the things you might enable if you feel like doing so is there anything they could do better? So if you have lots of comments in your service config file that you think are options that people generally want to enable maybe those should be config files that plug into this maybe it shouldn't be open SSH that provides it maybe it's a module that needs to hook into PAM auth update. In the general case this is available to all services on Debian by default because they use the PAMD common dash foo includes. So they're already hooked in. One other thing that's a known blemish in the common foo is that we really need to have a separation between interactive and non-interactive session handling and so I don't know if in the open SSH case if that's a cause for those additional commented out fields but there's stuff that we cannot enable in the common session file because it's specific to interactive sessions and it breaks stuff in non-interactive. On Debian SSH you have supports both so that doesn't help either. Another question from Sam. So Steve I guess what I would say to the whole building consensus and not getting bogged down in the details is that one of the things we should work on doing is teaching people how to facilitate consensus decision making. There are two aspects of it that I think are really important that we're kind of bad at. The first is making sure people actually believe their comment is something that needs to be decided in the form where they're deciding it. Sometimes it's reasonable to ask people if they bring up some nitpicky detail on Debian Devel. So are you just giving the person who's actually doing this input or do you believe that this issue is important enough that we actually need to reach agreement here because sometimes when you point that out to people they'll say oh no I was just thinking you might find my advice useful if you don't that's fine too. The second thing is that it's really important to actually leave the time at the appropriate stages in the process to get people on board in the early idea stage and then in the final proposal review stage basically people in a community can, if they're sufficiently motivated, bog down any process. It's just you're not a community if that's not true. It's important to actually understand that there's going to be a part of being in a community with people is giving them the time to actually learn and come on board and give them the time to digest your design and hopefully if it took you a year to come up with a design hopefully it'll only take them a week or two to digest it but when you don't give that time and work through the process you encourage people to bog it down and I actually think it's reasonable for the people to bog it down then and I think we could be much better about both of those things. Hello? Okay, thank you. So I first have a really quick technical question which is are you looking at using triggers for your maintainer scripts? It looked like they were very simple and might be triggerable but I wasn't really sure. I hadn't thought of it. I don't really have my brain completely wrapped around triggers yet. As far as the question at the end, I think you said the perfect is the enemy of the good and that's true and I think it's important to sometimes go with the imperfect at the beginning. If you had put in the Red Hat system six years ago would that have been a bad thing necessarily? There might have been some kind of a nasty transition that you had to deal with or something but it might have actually been worth it in the final analysis to do that. I'm not sure if it would have been worth it or not. The transition concerns were why I never did that. Not only transition concerns but policy compliance. Because I couldn't see a way to do that. The policy compliance. Wait until we had the full design. Some other examples. You have d-package source two up there. If you look at d-package source v3 I think it can be useful to design in a way to implement one and throw it away. So if you look at what I did in v3 it has multiple possible formats. I didn't really intend to have the one that I wrote be thrown away but apparently Debian wants to do that. But that's okay if it ends up that we end up with a version three that people like. So it can be good to just another example is you were using Deb Helper throughout the implementation of this. Deb Helper was basically implemented to be thrown away and we're in the process of doing that. Of course we've been in the process of doing that for going on six or eight years now but we'll probably get there eventually. And some of a few of the words that you encountered will go away though not all of them. So I think that both of those are important. I also think that delegating things to people just saying we trust you to go off and we're not going to micromanage and look at all the details and if it comes back and it's completely wrong we might end up tossing it out but not sitting there over someone's shoulder as a list and looking at every decision they make I think it'd be a really good thing because people do come up with good designs on their own. And if you run the design by a group of people that's good but you should be able to say well I know that these people have this set of concerns but I just can't handle that with something as useful as I can for the consideration. That's one point that I certainly agree with about I'm not sure what we can do better to empower developers to go out and do that because I think a lot of the things that should happen end up getting bogged down in the mailing list discussions and I'm not sure how to overcome that and maybe it comes down to the guiding consensus. I don't know if the depth process is going to help with this Buxy, you're involved in the depth 3, right? Are you finding the process helps that? Well, I guess Petra has the microphone so let's listen to him first and then we can talk maybe about that a little bit later. Yeah, a few comments about how to get things done. I believe we shouldn't be that afraid of taking criticism on the mailing list. I think that's the main problem people are afraid of doing something because they will get criticized on the mailing list or on RSE or whatever. Personally, I believe rough consensus getting feedback and then going ahead and do what you want anyway, even if some people believe it's a bad idea because if you believe it's a good idea at least someone believes it's a good idea and you should go ahead with it and of course sometimes it takes a long time because you have to take over the system 5 in its subsystem first before you can continue with your plans it's going to happen anyway and sometimes people come up with arguments or comments and suggest that actually change your mind because there are a lot of smart people in Debian and you should listen to people when they are giving suggestions or arguments but you shouldn't let them do the decision. If you believe it's a good idea still after people complaining or explaining use case that you never heard about, you really should do something different but if you are still not convinced after some arguments on the main list you should go ahead. I really believe that's the important thing to make things happen and I still say if it's a really bad idea someone will rip it out again and for the pam thing I have one question, one feature in Debian EDU which is really wanted and we are working on to get working is laptops, disconnected laptops we want to have LDAP authentication when you are on the network and cached passwords with the same login when you are off the network is that easy to enable with the new pam auth update thing? Yes, so are you using the pam secrets module currently or are you using for the caching or is this something that you haven't implemented yet? I think it's the cached credentials packet we are looking at libpam-secrets I think is probably the one. There is a bug in the pam LDAP profile in that it doesn't do the right thing with pam-secrets and it needs to be ironed out but in terms of the architecture certainly I mean both modules can provide profiles and they can work together module a couple of bugs that still need to be sorted. Good. I think Triggers was an interesting example of how this design process works. If we leave aside totally hideous row over the merging of the implementation the actual design I found the design process worked really well. It did take quite a while but I got a really good lot of feedback and I think pretty much everybody was happy with what we came up with and you just need to as the person being in charge almost of the design you need to understand what people want and then give it to them and I didn't find that really very difficult and also I was very pleased at the time I was wearing an Ubuntu hat and I didn't get any aggro about that at all which I thought was maybe gives a lie to some of that stuff and while I'm talking about Triggers, if anybody wants like consultancy on how it should work come and find me I'm hanging around in Hack Lab one. One thing that occurred to me is that if you are doing major changes to the system it's important to have a way back that's been one of the things I've been focusing on with dependency based boot sequencing you can try it out and if you don't like it you can return to where you used to be and for Triggers of course you can use it if you want to, you can ignore it if you don't if you don't force people to use it the dash as SH alternative is like you can disable it if you don't like it if you make sure that good ideas are always optional at least initially eventually everyone will be using it and then we can take away the option but if we make sure that there is always a way back for unsure people that are not convinced that it's a good idea yet then it's a lot easier to introduce it into Debian. That's actually a point that I don't entirely agree with you on I mean we've had this conversation before about giving people a way back it is useful in many cases to make it optional there are some cases where the extra effort involved in making it optional it's better to force everybody to deal with it and help you implement it than to spend more time up front making people happy about it so it can go either way One word about Triggers there are the facts that it was a really complex specification very few people were able to comment usefully so the kind of people that have an opinion on everything didn't participate in this discussion and it went forward so we should have everything all our proposals should be complex and to withstand not sure but well it's a reason why it helped now coming back to the depth process I'm driving the depth 3 currently and I try to do it in a different way because usually I have strong opinions on stuff that I want to do and I defend my opinions and here I try to go back and just say the long term goal and not go straight into detail I let people discuss I see if there is some consensus I choose when I have I choose something when I have to because people have different opinions and then I come back to a new round and say ok people have said that I think this one is the best consensus the best choice currently do you agree or do you have something else it takes more time but I think the discussion goes forward without too much conflicts do you also feel like it helps you recognize when the discussion is at its logical end because that's one of my hopes for the depth process is if we're seeking consensus explicitly that we have a way of curtailing the mailing list discussions which otherwise tend to be somewhat open-ended and trail off and end up down rat holes and everything else I think that's been a problem in the past with our mailing list discussion and I in your experience you find that the depth process is helping with that somewhat yes the number of comments are clearly going down after a few rounds so there's a point where you can say if nobody else has anything else to say I'm going to move it from draft to accept it or something like that and we'll see how it goes further but I think it's worth trying at least before I give back the mic to other people to continue the discussion there's also projects of course where you don't need to have some broad approval but in my case it's the new source format I as a DPKG container I can make choice and go forward exactly that's my question discussion and the problems that we have exactly I can make choice on this DPKG side but of course I cannot decide of course the project to use it I know lots of people who are eager to use it but I also know that GANF really doesn't care about the new format it's not a package or at all and it doesn't bring in much advantages other FTP master so it's just sitting on my patch not it's not against me but just it doesn't care enough to take the time right now so I don't know if you have ideas or we can solve this kind of problem would the DEB process help because we GANF would see that many people are interested in it or I don't know I don't see GANF in the room corner him at DEBCOM it's planned I'm going to attend the FTP master both and ask the questions there but just a question if you can comment on this question afterwards I'll be glad to hear your opinion just going back to Petters comment about making it easy to go back the other reason to make it easy to go back is that when you design to make it easy to revert changes you also tend as a side effect of that to make it easier for people to go forward to implement newer better alternatives and drop them in we find with DEBCOM that replacing it with CDEBCOM was really really painful because we had to go around everybody who sat writing depends DEBCOM brackets thing in their control files for years and when you when you design up front for your options you also tend to make it easier to do something better in the future I just wanted to draw out a point that I think has been sort of implicit in this Ian had mentioned how he worked on triggers at Ubuntu and that did work out pretty well on the lists there weren't any flames or anything Steve had mentioned how the Pamuth update stuff was implemented first it went into Ubuntu because it wasn't we couldn't get into Debian because of scheduling issues and I think there was a bit of a trend here I think you also had a slide up there about NSH being the default shell which I believe was implemented first in Ubuntu and we're now looking at implementing so it almost seems to me at this point that if one wanted to make a large change to how Debian made things it might be advantageous to implement it first in Ubuntu I'm not saying this is a good idea for Debian as a project but I am saying that there seems to be a trend here and that's something we might want to think about and in the case of triggers if Ubuntu had implemented triggers and Debian had not taken that implementation and used it Debian would have basically been screwed we would have diverged from Ubuntu to the point that we couldn't use any of their packages anymore or any of their packaging and so while we did review Ian's proposal and we liked it a lot even if we had hated it we would have still had to do something about that on the other hand just from the other side of the fence it would not have been in Ubuntu's interest to stand up in a position where we had to maintain this enormous delta of death but on the other hand I think that it actually got into Ubuntu before Debian had even gotten around to saying that we were going to accept it so I don't know I'm not saying that Ubuntu is trying to solve a task or anything like that I'm just saying that this is something that I think is developing in the project and we should really be aware of the issue that Steve has brought up is a big problem and has some interesting consequences That's an interesting point one reason that triggers went into Ubuntu first is obviously because at the time I was being paid by Canonical to do it but I did the design the design was done in Debian it didn't really use the Ubuntu design processes and because Debian doesn't have a formal way of signing off on the design you know eventually got to the point where people weren't making new comments on the spec and I decided it was finished in the same way as I had previously done about anything else that I've done in Debian you decide that people seem to like it and so you've implemented and indeed if Debian hadn't adopted it it would have been completely pointless for Ubuntu and I very much you know the whole plan involved it being adopted in Debian there was no possibility of it being any point otherwise really In the case of the PAM implementation I did use the sorry it was always the plan to put it in both Debian and Ubuntu I did use the Ubuntu design process because I found that framework very helpful to me and I didn't feel like I had a structure that facilitated that in the Debian side of things and so I did use the UDS environment and the spec process for developing that and bringing the design together so maybe there's something we can do better in Debian to have a formalized spec process I don't know if the depth process is it or not but well simply the wiki framework for developing a spec and all the issues you need to think about when doing a spec was something that was helpful to me I suppose in the last week there was this issue that came up on the IAC channels with dash and bash dependency and one of the things I mean I've been a driver and also in this discussion one of the people criticizing the current approach so take that with a bit of grain of salt what I have to say but I think one of the problems is that on the one hand we certainly need people to make decisions and like you went ahead and implemented PAM update without great talking about it and you just did it and it was a convincing proposal that's necessary but when it's something that actually touches the entire distro or something that is very much of a religious thing as well I can still hear you with the mic hand somewhat of a religious change as well then I think one of the important things so these executive decision that's better these executive decisions they are important to be made but if it's an issue that sort of touches everyone then you need to give everyone a chance to get at the information and to be able to have a word in this and then after you get to the point where everybody had a bit of a say two weeks, four months, six years whatever it is then make that executive decision I think the depth process is a step in the right direction I think it is pretty much like the blueprints or like a wiki based approach there's probably still rough edges to it I think it's important that if you want to drive change in the distribution then you should make sure that you make it easy for everyone out there to see the pros and the cons at all points and times and not say look at this thread on the mailing list which has been going on for six and a half months because it's just a pain to do it and you can't find the information but if you as the driver for a change maintain a central resource with all the pros and cons that's a good basis for discussion and that's also a good basis to make executive decisions now I also have a second small point because you were on your slide earlier you were asking how can we actually make sure that we don't take six years to implement these changes I've been doing some research over the last couple of years and I've been using a method that I would like to talk about during my talk tomorrow I think on Sunday no wait next Thursday it is at 10 o'clock whoo yeah I know it's Thursday it's my research results presented but I'm also going to be talking about this Delphi approach I think that it is something that we could learn from and possibly even institutionalize it within an open source project and basically what I think Rafa earlier you hinted at this your DEP 3 process right now where you are actually interested in it but you're trying to stay away and keep your interest in the background so that other people have something to say and the Delphi process could have someone that is actually not really, does not have an invested interest in an issue just collect information and moderate a discussion and that way hopefully find consensus a little faster so sorry I've been talking way too long to respond to your first point I think it's interesting that you draw a distinction between switching bin SH default or how we handle bin SH one of these affects everybody and so PAM is what I mean it's transitively essential you can't get rid of it on the system it affects everybody's system bin SH everybody seems to have an opinion about it but in point of actual fact the implementation I well I'm in that discussion and maybe we should have that out of band because I