 During the conference some of us who are interested can put can get some of this work done concretely this week and I think we have a lot that we can do with GPG and I'm hoping to, hoping to figure out if there are any concerns that we're missing and like get kind of a roadmap out of here. I'm also on IRC right now in debconf-room327 but hopefully we can get everyone to consolidate and use the Gabi chat and the Gabi page just so that everyone can share the same screen. The Gabi screen is being, it's being, it's up on the screen here so if we can work there that'd be good. I'm going to monitor IRC as well. We have a microphone if you have comments. Yeah, so I'm DKG. You have to press short ones. It's not, it's not. I'm Eric Dornlin, I'm the DGNU PG2 maintainer and we have these kinkers on the on IRC right now who's currently, oh there we go. Welcome, you just joined on Gabi. I think you just installed Gabi. He's the main GPG1 maintainer right now. Right. So a bit of a bit of agenda bashing here. So we've got a bunch of different topics that people have put up. So I'm up for just diving in. If anybody has any other particular topics feel free to call them out or edit the Gabi document. Yeah. I don't know how to do that here. Is that okay? Okay yeah we've got the path over there. Alrighty. Should we explain the current state of the world? Yeah. This came up at the key ring mate discussion also. Right. Okay, I guess I'll explain. So obviously GNU PG's have been in the archive for a long time. There's currently two supported versions. The sort of existing GNU PG1.4 branch that is a very standalone tool. It doesn't really depend on any libraries. It doesn't own crypto internally and there's the newer GNU PG2 branch newer in that it's been around for I don't know five years now maybe. And it is much more modular. It depends on on the G-crypt to do its actual crypto. It supports some other things that it supports like what does the SMIME that GPG1 doesn't support. It's the thing that provides GNU PG agent. It's more modular but it's mostly compatible. Or it's a backwards compatible with GPGV1. Yeah. Sort of bug for bug compatible maybe with the API. Yeah. So this is actually kind of a confusing setup I think for many point Debbie and who want to know just like what what GPG am I supposed to use and the nuances and the differences between GPG and GPG2 from the user's point of view I think tend to be very minimal. And in practice the fact that we have to the upstream is supporting the 1.4 branch and the 2.0 branch and working on the master branch which is 2.1 which is not released yet but has been in beta for I think at least five years literally. Maybe four but it but yeah so that so 2.1 is going to come up here we've got that on the list. So Fedora uses GPG2 by default. The Windows GNU PG installer uses GNU PG2. I believe GNU PG1 has been kept around by upstream mainly because of the lack of modularity because the idea is that it should make it easier to deploy on systems that may or may not have dependency management available. And we actually have good dependency management so I'm not so sure why we are sticking with GPG1 as as the default except other than the fact that it's pretty scary to change a piece of software that's this critical to Debian that's as complicated as GPG is. So one question is what can we do to make it so that people can try a different thing as the default if we want to consider the possibility of actually making a change to GPG2 as a default presumably that's going to need to happen in stages and maybe that means we need to make it easy for people to switch to GPG2 and see what breaks. Perhaps we should have a perhaps it would make sense to upload a transitional package to experimental that is packaged as GPG with all the binaries appropriately set that is incompatible with old GPG and the current GPG2 packages as a transition and just that way it's a smooth upgrade path and you can try it in experimental and see what it would be like to have only one GPG. Okay that's an interesting proposal I hadn't thought I feel like that's pretty radical actually. I mean I see alternatives up here as a as a the transition path that I was thinking of as being a little bit more a little bit more chill where if we we would need to upload a new version of new PG that installs itself as GPG1 and sets up at the alternatives where itself is the highest priority for a user bin GPG and then once that's in place then you could say that GPG2 could add its own at the alternatives option. I already on my systems and my systems at work routinely divert GPG user bin GPG to user bin GPG1 and then create a sim link called user bin GPG to user bin GPG2 and I've done it for over a year probably you still have all your hair it works absolutely fine I can't even tell the difference okay so alternatives would be nice to let me do that quicker and more easily on a new machine but but a package that can do a divert instead would be also perfectly acceptable solution so one major issue with using alternatives for user bin GPG is that GPG is used programmatically really often so it would be unexpected if programs had to cope with potentially different versions of GPG on different systems if they didn't call it with an explicit version especially since there are scripts using GPG that are not written for Debian so same problem is GCC for example the reason we don't use alternatives for certain things or Python or similar sorry oh yeah that's a real distracting let me turn that off so so mostly the the command line interface is the same there's probably a few tiny little corner cases where it's not but basically you can run whether it's GPG1 or GPG2 if you assume I mean so GPGV2 actually adds a few more command line flags obviously but if you were you if you're expecting it to have worked with GPGV1 it should work just fine with GPGV2 I haven't seen any cases where it hasn't and you're saying that you've done this diversion and none of the tools that you've used have broken it and so I think that's the alternatives gives us an opportunity to say hey we're gonna set it up we're gonna set the default to be GPG1 those people who are interested can just update alternatives and find out I mean and particularly you know you probably send mail to DDA and say hey if you make heavy use scripted use of GPG or you think you might be making heavy scripted use please try this out and let us know because we you know we want to consider changing the defaults so I want to know if anybody is gonna really object if we try to push for something like that there there's a bit of tooling built around GPG like Perl modules and Python interfaces and so on and it might be good to sort of I don't know file bugs or take special care to talk to those people before or as part of this sort of semi-transition thing you're talking about yeah yeah so it's a little bit tricky because GPG is are people even declaring explicit dependencies on GPG isn't it because it's just gonna be there well I have a fairly extensive project that uses the Python Canoe PG interface so if the command line broke because I that's I believe that's how it uses that under the hood it just calls GPG command line so if that command line interface broke then my test cases would definitely let us know I suppose that so okay it might it be something I'd be worried I'd be willing to experiment you know especially if we had alternatives that'd be really easy for me to test it out okay test case and see what happens great so yeah I mean more generally the impression I'm getting from what you're saying is it's supposed to be compatible and the only reason you think we might not want to just go forward is that there might be bugs in the compatibility yeah I think that's yes I think that's the case there are other there's a couple of other concerns about things like Debbie installer which needs a bit of GPG and we I guess just need to figure out what those parts are is anyone from the DI team here or online on IRC so so I'm just reading what I mean we don't we don't again we don't have to we can do this alternative without actually changing anything about the installer so the installer can still have right as long as we can ship GPGV and not GPGV1 right exactly yeah the so the tool that just for the context here the the installed there's there's a separate package for this tool called GPGV which is just a light it's a lightweight binary that only does signature verification doesn't do any of the other GPG things so both GPG1 and GPG2 ship this and there's a UDEP for it because it's needed by the installer to verify things like the apt signatures and things like that right yeah so there's a comment online about about the sizes I believe that new PG itself is actually smaller to be G2 is actually smaller than new PG but that's because it's it's got a lot more dependencies and the dependencies are what make up the rest of it yeah I mean it's I wouldn't say it's a lot more dependencies but it's I mean the door is one is is LibG Crypt it depends on live GPG error which is I don't even actually don't know that much about you were here is a is a is a odd little package that just supports error handling across a wide variety of platforms in a in a common way and there are a couple other sort of portability layer things that it that it provides and there's one other small library called LibAswan which is handles the protocol between GPG and GPG agent and I think that we have G Crypt dependencies already in that that are going to need to be on the system so I don't think pulling in G Crypt is particularly expensive side yes I think yeah my last examination situation was that G Crypt was already there maybe this is just my misconception but I had the impression that GPG to more or less requires you to use GPG agent that's not the case that's not the case okay GPG 2.1 will require the use of the agent I think okay I don't think the GPG 2 requires the use of the agent I mean I've seen people struggling with things that used to do direct pin entry or pass raise entry and this sort of break I mean who knows where the bug is right but so that is a potential point of friction I guess yeah it's a bit anecdotal but that's just my impression yeah just yeah it does not require it but yes 2.1 will require it so I just went to my build Sid Chiru unfortunately I can't tell you how much space GNUVG1 takes because I've already got it but I asked out about GNUVG2 and it suggests installing 183 megabytes of stuff including font config at a Thai hyphenation library and an enormous pile of libraries yeah so one of the things that the current so the current version of GPG2 will recommend or I think depends directly recommend or straight depends on GPG agent which depends on what's that tool called the key yeah pin at pin entry and the default alternative for that is the GNOME version so it will pull in a lot of GNOME things potentially but we can discuss that problem slightly down this list so I'd just like to answer the question about recommends versus depends if I ask without recommends only a hundred and seven megabytes okay worry so it sounds like we need to look into that yeah I think that's the I think that's one of that second last line there sorry before you move on from that do you know where Lib GPG ME fits into any of this does it have the same interface between the two versions or yeah Lib GPG ME so people who don't know how this stuff works which is probably everyone because I'm not yeah it's Lib GPG ME is a library that's supposed to make it easy to use GPG from C and what it actually does is it forks a GPG process in the background and talks to it over a separate channel and GPG ME itself is actually capable of picking a different GPG binary to work with so I think I think it actually should be fine with and not care so I also have a tool that uses Python and the GPG interface to do things which is shelling out or forking behind the scenes and I'm wondering you know for those of us that want to do tools that reason about or talk about key stores what's the right way to do this going forward especially if there might be alternative implementations of OpenPGP Clint you know what's the right way to think about doing that should we continue to do stuff directly or indirectly through command line wrappers or is there if you're working with GPG that's the only option at the moment if whether that's the right way to do key management might be a separate discussion than just how do we maintain GPG itself in Debian yeah sorry I don't have it I don't think I have a good answer that I want to know I mean presumably they should be using GPG ME if they can if you're using GPG for your OpenPGP implementation right yeah I mean that doesn't help with different ones but it does help with yeah so we are actually 20 minutes in and I want to make sure that you get to some of these other points it sounds to me like there is a people are okay with the idea of moving forward with the SC alternatives approach and maybe we can get some people to commit to volunteering to switch to GPG to as the default and see what what breaks for them so I want to talk about how we deal with the maintenance in terms of package package GNU PG so and I don't know whether we whether that's like I've got VCS religious words up there sort of but so I to explain the current situation GNU PG-2 is not actually part of the under the umbrella right now of the package GNU PG LAF project the reason for this if I remember correctly so a few years ago I sort of said oh yeah we should do that and then they were like sure you should switch your get repo to conversion and then put it as part of the project and I immediately lost interest so I'm perfectly happy to add this BT maintained I just don't want to use subversion yeah so that that was the sort of that and that's how I got left and I haven't sort of re-engaged in this but so Daniel's interested again and yeah I'm interested in I also don't want to maintain things in subversion if I can help it so so I mean I I think we should have a get repo in for for GNU PG-2 and if we don't want to move the GNU PG-1 stuff out of SVN that's fine we can keep it keep that that way and just because you're part of the team doesn't mean you're gonna have to be sucked into dealing with subversion if you don't want to be so so Tyson there says I'm very open to changing VCS excellent so that's good so do we have consensus then that we're just gonna move stuff to get and it's gonna be a gradual process move it please okay all right done awesome I love this kind of religious wars less of a war more of a yeah great so did you want to talk about cross-building yeah so we had so so cross-building is an interesting thing that we've run into recently when I uploaded the new version of live GPG error despite being a simple library this designed for portability it was actually not able to cross-build properly so cross-building is creating a new creating a Debian from one architecture for another one sort of bootstrap a new a new arch and the reason that we want to be able to do this in Debian is because we'd like to be able to say that given one Debian archive on one functioning machine we should be able to get back to a functioning Debian on all the other archives and so it's important to try to continue cross-building and at the moment I think we've resolved the cross-building issues from Libby GPG error but because GPG at least some pieces of GPG are close enough to core in particular I think the G-crypt is close enough to the core of what we need in Debian that's that's like part of the basic thing that we need to get it started to get the package to get the baseline Debian system started in booting so that needs to be able to be built across platforms I haven't I don't think I've run into anything else there but if people do run into cross- building problems you know we're kind of in the critical path so it's worth being aware of that is anybody here doing cross-building I'm assuming that was helmet filing bugs for history bootstrap effort so yeah so helmet is now running a thing that tries to reboot strap Debian from scratch with a load of evil scripts because various things don't work at the moment but it still means he notices when things break and I guess yeah so the general requirement is that anything in the core system needs to be cross-buildable as well we're trying to get to I guess GPG v2 has much large dependencies GPG 2 is not currently part of the strongly connected component which is the core of stuff that's all loopily dependent on itself and until you build that you can't build most of the rest but it's GPG 1 GPG 1 is okay yes so so as we think about making this transition we may find ourselves in this spot exactly as soon as you make it an important kind of thing because like apt needs it or something or your deep package I know I'm not quite sure which of the core components requires GPG for something does it's certainly apt then yeah that will be and if it's penises are much fatter as discussed that'll be a problem right maybe it's trapping harder so the less the few things it has to depend on the better okay thank you so if anyone would like to try to cross compile or do this but trapping with GPG v2 that would be interesting I don't think I have the expertise but yeah there's there's also another funky thing with the switch from GPG to GPG 2 which is that we need to cross-build GPG for Windows for the devian installer yeah and so we may end up with problems cross-building GPG 2 I know GPG 1 works fine I don't know about GPG 2 but I'd be happy to help with that okay that that is interesting I had no idea it should I mean I yeah as current GPG for when that shipping is shipping GPG 2 so I just like so you say you have the expertise for this all you have to do when when if once cross-compilers are in and you can the moment you have to point an extra repo to get the stuff you literally type deep package build package dash a architecture thing right you say you just use deep package build package with a package build package dash a Windows dash we haven't known for Windows yet he'd like to but for the normal normal Linux architectures literally it should be that simple so you should be able to try cross building painlessly now the moment you'll find things are broken but it really is trivial great okay that's good news any other points we want to raise about that those concerns it's good that they're on the table and I think we're we're gonna run into problems as it goes forward but it's good to know like what we're looking for so so I want to talk a bit about 2.1 the I've got to hear is the eternal beta so 2.1 offers some features that are quite divergent from 1.4 and 2.0 so in particular it offers elliptic curved support so this is a new kind of crypto that is you know does a similar thing to what RSA and DSA do and it and it offers a new form of key storage called a keybox which is different from the way that new PG currently stores all of its public keys and it for public or I thought it was for private I think that the keybox is supposed to be for public I haven't tried the latest data and it and and there's actually a radical change in the agent for open PGP currently the SMIME agent behaves this way right now and in the 2.0 agent but open PGP okay here's how the new PG agent works it's a passphrase cache so you put your passphrase in it and then group you says oh there's an agent let me go ask the agent for the passphrase I get the passphrase I unlock the key and I do whatever I want all in the new PG process the proper way to do a cryptographic agent is that the agent retains the cryptographic material itself and then clients to the agent send a cryptographic request to the agent the agent does the cryptographic operation and hands the response back to the client so that they said the client which is probably much bigger and hairier than the agent never actually sees the key material in its memory at all so the key the secret communal is never exposed the 2.1 agent actually is a proper cryptographic agent for open PGP and the way that secret keys are handled is very different so yeah the the problem there being the interoperability now with the 2.0 and the 1.4 is reduced in that when you first run the 2.1 it will convert the keys into this new format and now you have the old keys and the new keys and the two different versions yeah we'll look at won't like they if you change something much a private key in the new format it will not be retained in the old format and and also like if you start out with just the 2.1 you won't be able to run the older tools either right so are people actually going to have to go backwards I mean it sounds like the new one should replace it and we should just do it and we expect nearly everything to work and if things are broken we should just fix them so the number of people who will need to make changes in the old style is small you're just worrying about the things that might possibly get wrong yeah yeah yeah I mean maybe that's true down great they're not supported right so so I what I want to do is I want to put the beta into experimental and I want to do that before DebConf is up and I want people to try who are interested in using it to try generating elliptic curfews with it and see what happens to them so with various transitions and possibly new recommendations for handling interfaces to this stuff do you think that keybox will introduce any opportunity for at least opportunity to make recommendations about how to handle private key material I know people do it in a variety of different ways from it's just on their disc to it's in a e-cryptoFest file system to it's on Luke's to it's on a smart card what do you think I I don't know they else have any thoughts on that that wasn't that give me them like I have an answer yeah I don't know there was a request in the key ring main session for clearer stronger suggestions about what to do in general how to manage a GPG key ring and I Debbie and it's traditionally not been very good about making stronger recommendations there's a web page that rise up hosts that's a sort of accumulation of open PGP best practices that many people including myself have been contributing to that tries to make concrete specific you should be doing these things suggestions I don't know if we want to try to endorse that as Debian or at least point people to it from the Debian wiki or maintainers guide or something it it was pointed to in the key signing documentation on the previous subject about the interoperability of the key rings it just seems like that's something that you put in a news entry in the package to warn people about that and then just go forward okay I'm surprised that this is not upsetting people yeah I'm pretty happy about it this is sort of why I had been reluctant to actually package this so far because I was worried if I didn't know how to deal with the the change in the key format but if people don't think it's much of a concern all right how hard would it be to write a tool that converts it back I assume not that hard so why don't you get willing to convert and try it out and if it fails figure out what it needs yeah I don't think such a tool exists yet in the in the 2.1 but but seriously I mean that's what we need we need some we need some willing guinea pigs to do that maybe I might be in one of those guinea pigs presumably if 2.1 can output an ascii armate key then you can just practically pipe it back into GPG 1 that's true that's a good point although GPG 1 also has problems with merging secret keys and they're only exactly what they are but I've definitely run into this before where you can't update your secret key properly if it wasn't done within GPG 1 I don't know the details anyway it's worth it this is something that we probably need to do yeah it's good point that that sort of tooling would make this but hopefully remove any lingering objections yeah so have we covered yeah I mean I guess the other thing that maybe we glossed over is that 2.1 will require the agent right that's the little point of this is now the agent is no longer optional it will be required it will GPG should it will launch it if it is not launched but it won't do they won't fall back to the sort of the current two-point of behavior if the agent's not there it just prompts you on the as in the way v1 does it right but that will no longer happen so if it launches this agent and I don't have an X display what happens it will ask you in the terminal there's a little just like it did before it will basically look just like it did before there's a there's a pin entry curses yeah and then I believe there are there are other pin entries that people are putting around including a pin entry for dumb terminals so I don't know just how far away from an from an X session your personal system is so how does that integrate with Matt which at the moment will do the pass phrase query itself and then pass that over to GPG and does that in its own curses environments and if you're going to try and spawn on other curses thing around it then so I believe it in entry curses actually I don't know exactly how much does it but I believe it in entry curses take control of your TTY stores what's there pops up its own dialogue on top of that and then once you put it in it let's go to TTY and we will stay running until I manually kill it at some point well this I mean the pass phrase is needed I don't know what the duration of the I never as someone who handles all their email on the code server which doesn't have X is running stuff on screen and has multiple users I don't actually want extra processes sitting running around all time whenever I'm going to use them very rarely I agree with that and but this is this is part of the upstream architecture and we should if we were going to push back on that we need to make a clear proposal for how else it should be working yeah I mean you could you could imagine a situation where if the agent isn't running persistently it just starts up as it's the does the pin entry and then goes away right so yeah maybe maybe I don't actually I haven't read the agent man page in a while but it may have like a lifetime so maybe you could just set that to be zero or one second sorry on my recurring theme of I already did this but can't remember what I changed in the convict to make it happen when I asked my mutt to sign it invokes pin entry GTK for me but it falls back to curses if I'm in a shell session gets the stuff and goes back to mutt and mutt does its thing and it works up to be fine and if I don't have an agent running it sports one what how long does that agent live the default for me okay but I imagine with more time I will go back and review what I did to make it happen and write it up somewhere okay can you send a pointer to that to the package community mate when you get picked up thanks no not for sorry I heard your question so you're asking if it's only for security operation so if you're just doing verification yeah it doesn't the agent doesn't need to be involved so do folks want to pick it up do you have another you mentioned the elliptical curve changes in the cypher suite does is there along with this change which is a good one is there any more generic cypher suite flexibility being built in to make this a little easier next time I think we have too much flexibility already I'm not sure I guess I'm not sure what you're what you're asking for it just seems a elliptical curve functionality in GPG has been a long time coming it has but I don't think that has to do with with it with the flexibility of of the protocols I think it just has to do with the fact that nobody has you know leaned hard on the PG and push the changes in and I actually think that one of the reasons that it's been in beta for four years is that we haven't put it in Debian and said hey look there's some wide deployment things that people are using it you know I mean there are bugs it's still in the non beta versions of the new PG that you know we find and they get fixed and it's still considered stable so I think I was putting this into Debian would be a real push forward towards actually having functional of the current support I assume Mika that one of the things that you'd like to avoid is us finding ourselves in a situation inadvertently where we end up with some default like dual EC a DRBG and or a various other you know open SSL sorts of things so I guess that means I'm signing up to do auto package test auto package test well I mean doesn't it seems like we need to do something some kind of continuous integration so we checked for the most at least the most obvious things that can go wrong I'm not sure I understood what are you proposing well you know I think that what what we should do is well there's two things really one is we should elaborate what flexibility there is so we know if there is a choice of and I'm not really familiar with with open PGP but if there is a choice of cipher suites for example you know we don't want to find ourselves in a situation like with TLS where you know one of the options is no or you know one of the options is a duly CD or BG we kind of want to like not make that an option yeah so I mean I feel like this is pointing a little bit towards this point I've written I put up here about divergence from upstream defaults and I kind of wanted to get a sense of what people think about that Josh did you want to do you have another yes so we've had lots of specific guides about things like use shaw 256 and shed of shaw one and various other improve the defaults and similar I'm kind of hoping to new PG 2.1 would simply fix those defaults upstream if the if those defaults are broken let's fix them for everybody as opposed to just fixing them in Debian and breaking user expectations I agree but how many flame wars have you been in on new PG develop upstream about more than we've been in Debian well so so there are there are at least there are at least three regular requests on new PG develop from different people about changing the defaults and there are these change the default cipher suite the default cipher to AES change the default digest algorithm to shaw 256 and change the defaults generated asymmetric key to be RSA larger than 2048 because currently the defaults are 2048 I believe the defaults right now are RSA 2048 SHA one for signatures and certifications and cast five or something for the for the cipher so the upstream has continually pushed back on all of those three things and they're not doing it they okay so if you make a certification an open PGP certification using shaw 256 then shaw one is the only required digest algorithm for an open PGP implementation so then theory someone who's using an open PGP implementation that only knows about shaw one can't interpret your signature they're 12 years old I'm on the other I'm with you on this argument and I'm just telling you what upstream say is there any way GPG could provide both certifications as in if you sign a key provide the old and busted compatibility shaw one and the shaw 256 cert yes make that the default for interoperability we have five minutes left left and yes that's been proposed but no one supplied patches upstream for it so so next year that conference in Germany can we make sure we get Werner Koch to attend that would be great yeah we can ask him so I mean on the question of divergence from upstream defaults we should we in Debian should always diverge from upstream default configuration in any package whenever we think the upstream default is wrong and I don't see any difference here to any other occasion I was frankly completely boggled to discover there was a set of wiki instructions that told me to use weird different configuration for my GNU PG to use better ciphers that you know I thought why is this not the default at least in the Debian package which we do control I'm I'm with you on that and frankly if someone only has a 12-year-old open VGP implementation it's buggy as hell and their system is not secure anyway so I don't feel the need to interoperate with that so unless people think that it's really a terrible thing for us to diverge from the upstream defaults on this I'm leaning towards diverging from the upstream defaults what are the defaults for people who distribute GPG that are not upstream most notably other Linux distributions GPG for win etc and are they open to changing the defaults in concert with us I don't know but doing some outreach on that would be great that's a good point if we change the defaults to be more secure in in our GPG I mean a GNU PG most most users are already long-term users and have a gate dot GNU PG in their homes which may have wrong configurations so we have to make sure to push the thing they added the notion that the knowledge were changing defaults so they are they do it as well when the defaults have been set already yeah I mean some sort of tool that actually checks your configuration to make sure you're doing the right thing would be welcome I think I don't think anything like that exists so and as far as key management goes I mentioned this in key ring mate but open PGP tools has this has this lint check which checks a key which looks at a key and says is what you're publishing to the outside world look reasonable yeah which doesn't address what specifically is in your GPG sure sure but yeah maybe maybe there's room I don't know yeah we're volunteering Clint for things maybe all right thanks Clint oh we should go ahead I guess we're running our time here we are nearly out of time I'm here did you want to mention anything about the UK sorry can you just announce that people who are interested show up I'm sorry I still use 2k key and and but I have a specific reason to do that I I have my private key on my token USB token and I will have a talk on Thursday morning so please join me join us thanks we should talk I guess about the the package dependency thing yeah so if we have enough time so yeah so as I was explaining the one of the reasons that GNU PG is a little more heavyweight is that it pulls in pin entry GTK to as the default sort of alternative for pin entry which can obviously if you're on a if you're on a system that doesn't have you know I'm installed already it will pull in a bunch of stuff that you may not want the reason that this I made this choice a number of years ago is that it does provide a better experience to users on graphical desktop environments right because if the using to you to actually get a you know window in their face to enter their pin rather than rather than something incurses and for tools that are behind the scenes calling out to do PG can actually be better if there isn't actually a terminal right there to fall back to but I do recognize that this is maybe expensive I'm not sure how to handle it better they would have any packaging recommendations for how to how to figure like auto guess the right dependency so this used to be an issue a long time ago with pin entry as well and the obvious solution would be make the GNOME and similar desktop meta packages depend on the pin entry graphical programs hopefully there will be a pin entry GNOME shell at some point or it'll just be built in and have the default pin entry be the tiniest text based prompting or whatever is built in and then if you install a full desktop environment as part of your initial installation it won't bother installing the alternative because it already has a secondary alternative sounds good yeah it sounds like a reasonable suggestion does anyone have any problem with that or who do we need to talk to you on the guide idea to make that happen because that's good that means pushing the change there to right yeah someone want to volunteer to although it's possible that some of their stuff already pulls us in anyway it could be indirectly okay so we'll so we'll we'll try moving the pin entry default to be there that's the only one I know that pulls in a lot of stuff if there's anything else that people notice that I haven't noticed feel free to let us know on the the package can you PG paint list and feel free to join package can you PG mate yeah if you're interested please you know what it'll be and get we can accept patches join the mailing list and let's talk it over thanks this was remarkably uncontentious yeah I appreciate everyone's bearing with it let's get this working yep thank you