 So this is a bit different from the usual dog and pony show about how cool not much is. This is about how uncool bits of it are and how we can make those better. So in a few minutes, I'll bring up the Gobi with the agenda on it. If you want, you're welcome to follow along in Gobi or edit that document. I think a lot of what's on the agenda, I'm going to put Daniel on the spot and get him to talk about some of the more cypher punk aspects. But I thought I'd start off by showing you a picture. Cat's code, so almost as good as cat's. I'm starting with C. So is anybody desperately trying to type in this URL? I've got it written down that I can't bring up the Gobi or something. Well, I just did, so it should be visible. So don't worry about if this document is too big and the diagram is too big and complicated to follow. That's more or less the point. So worth, as some of you know, started not much as a set of command line tools. And at some point, Sebastian Spitz, I think it was, came along and said, hey, wouldn't it be nice to have Python bindings? And so couldn't you split out most of the functionality into a sharing library and then we'll have Python bindings? And then things just sort of got out of hand. So currently there are more or less maintained Ruby and Python bindings. There are also Go bindings, which I desperately need somebody to look at some patches for. There's a shared library. The shared library delegates a lot of grunt work to Sampian and so our back camera man here today. I don't know if that's coincidence or not. And a lot of work to Gmime, which is in some sense part of the GNOME project. I don't know exactly where it's used in GNOME, but anyway. So it's a nice Mime parsing library. It does depend on Glib, so if you hate Glib, it's probably not for you. But even a GNOME skeptic can be pretty happy with this library. It doesn't pull in system B or anything. So the CLI is still there and it's still somehow one of the main interfaces. And then there's a bunch of clients built on top. So in this box, I count one, two, three, four, five. Yeah, that's a lot of clients, right? And so with varying degrees of nicheness. I mean, okay, you know when your biggest population is using Emacs, that niche is more or less a given. But still, I guess at least quite a few people use not much much, because it's a simple sim link farm maker and a lot of us use not much Emacs. And there's an experimental GTK client and MIM client, which sort of works well, because MIM people don't really like the idea of using editors for things that are not defined by Kernan and Richie or something. So all right, so that's my spiel about introducing things. And maybe I'll turn it over for a bit for Daniel and we can trade back. Sure, yeah. Sorry, I feel like my voice is going a little bit right now. I don't know. My voice is going. So it's all right if I'm not that loud. So, is it okay? Can you turn it off? No, can I scroll down? Yeah, sure. I always feel bad operating someone else's computer. I don't know how. Would you like my GPG card? No, I wouldn't. So not much is a male reader and not a male composer generally. Although the front ends that you just saw have male composition mechanisms built in. But there's a bunch of different potential security issues involved with reading mail. And that involves basically we're not even fetching mail and not much, right? Something else in the back end is supposed to do that. You're just supposed to look for a level. So it's even in this very constrained space, there's a whole bunch of privacy and security related issues that I would like to see not much addressed better than it currently does. So Brandon and I were brainstorming a little while ago and it turns out there's actually tons of stuff just within this constrained space that I've got a mail there and I want to render it. And how do you support privacy and security issues with that. So I'm just going to run through some of these and if folks have suggestions about other things or hey, I've got an easy way to fix that, shout them out. So we can just go back and forth on this. So message ID collisions is something that we've known about a lot in the past. We've had discussion on the mailing list and nobody's ever come up with really a great way to solve that. Not much indexes all messages by message ID. And an attack that you can do against this is that I can say, oh, here's an important message that I don't want Werner to get. I just saw it on the mailing list. And Werner hasn't checked his mailbox yet. So I'll send Werner a new email that says, I like kittens with the same message ID. And then Werner will not much index his mail and that message ID will come up and it's a crapshoot whether it comes up with I like kittens or whether it comes up with the actual message that's relevant. Plus I could send a hundred messages with that message ID. They all say I like kittens and now it's a hundred to one chance that he's going to get that I like kittens message instead of the actual important message. So this is actually pretty deep in the structure of not much that it's message ID index. And I don't know how we should address it. Not much knows when there are multiple files that have the same message ID. But those files rarely have the same digest. Even if you strip away all the headers, they rarely have the same body of the message because you'll get things like footers that are stuck in by a mailing list, which is a common situation where you get another message with the same message ID. So proposals for how to solve this would be welcome. I'm not seeing anybody. Is it hand up because you've got a solution for that? No. I was wondering if you said a hundred to one, is it truly random or is it more deterministic? It depends on how you populate your mail there. Right? And because not much is agnostic about how the mail there is populated. So like if you use get, I think it would depend on, are you using get mail, are you using fetch mail, are you using... I don't... Does anybody know... I think it's like first come, first served, right? The first message they didn't notice is it has a message ID, but I'm not sure. But supposedly not much somehow knows if several mails have the same message ID. Right. So I can tell it to show me all the files that belong to this message ID. Right. I think yes, it's actually legitimately handy. Yes, yes, that's a good thing that's something I like about not much. But one thing that could at least alert people of this problem is that in the user interface to show how many messages there are with the same. So how many copies you have in your inbox of the message you're actually viewing now. Okay. So what do I do in a session? 100, and it's a mailing list mail. Okay, but so what can you... What do I do if it says two? Right, because the attack is still there with two. Yeah. So now what does the user do with that information? I'm always wearing with... we're trying to do privacy security sensitive things. Giving the user a warning... And the other difficulty is... I don't think it's such a warning but just have this information. But it's also useful in perfectly legitimate cases. Do you have a fuzzy match for how different they are somehow? Some sort of heuristic... It's 90% the same or... I mean, you could take the body and you could take the G-Mine built sub-trees and see if there's a sub-treed of that. I mean, this is a traditional deduplication problem. Somebody else could tell it. Well, I mean, it's just a problem because somebody at the very end of the message, a lot of times it's just boilerplate you don't care about. So if somebody asks you to say, please disregard this message. I mean, and so there's no way you can really know that. And of course it is the common case. You're almost... a lot of times you're just going to have a count of two or three or whatever because you'll get it once through the man list and once sent directly to yourself. You know what I'm saying? I was about to suggest fuzzy search as well but if you're worried about textual attacks, there's a huge difference between I do and I don't. I'm quite sure fuzzy search will really catch you. Right. Okay, so I'm just going to run through some of these. I must... I think I don't want a rat hole entirely on this, but on any one. But if folks see one of these and they think, oh, this is a project that I might be willing to try to take on, I mean, guidance if you're a proposal like add an indicator in one of the standard user interfaces. And some of these are concrete tasks that we can just say that's something we're working on. So we have this issue of rendering rich messages and this goes up sort of all the way to the front ends where, you know, message comes in, it's a multi-part alternative, there's a text HTML part, or you've got jpegs, you're rendering the jpeg. How do we make sure that that stuff is clean and safe to display to the users? And that's an issue both in terms of things like executing JavaScript in some context that's not properly constrained. It's an issue in terms of doing remote network fetches, period. I believe we actually had that problem until recently by default in NotMuchEmax in that if you were rendering the text HTML part, it would just gladly go out and do network fetches. And that meant that all of the people who like to do click tracking to see who opened the mail when actually got information from NotMuchEmax users. So can we filter network access? Can we constrain whatever renderer we're using? So we're also dealing, I mean, no email discussion about privacy and security issues would be complete without talking about encrypted and signed mails. And since we're doing the reading, it's about the question that needs to deal with are about decryption and about signature verification. And so there's some common attacks that you've got there, including signaling to the user about whether a message was signed, which parts of the message were signed, who they were signed by, what do you do if you can't verify the signature, all of these things are sort of usability questions that bring... And can I send you an email that looks visually exactly the same way that a signed email would look to you? If I know that you're using NotMuch, can I craft an email that has the right kind of font, the right kind of colors, whatever, to verify as building was a signed message? And is there a way that the user can distinguish between those two cases? In browsers, we traditionally would distinguish between the Chrome of the browser and the content of the page. We have to think about that same question in the context of an email client. I think this discussion that sort of came up in Baroness GBG's session about targeted attacks versus mass attacks is relevant here. We should first worry about the attacks that work everywhere, like click-tracking, and then attacks which target NotMuch seem optimistic to me. Well, unless you're known to be a developer who has a workstation that's worthy of compromise, that's a high-value target. I don't want to name names, but there are people in the room who are high-value targets. You could also be a developer who knows the people who are known to be wanted by the agencies. Or who build operating systems that are only used by people who are valuable targets. There's a whole set of reasons why NotMuch is meant to be targeted. So yes, and we want them both. Yes. So do people have a sense for how to deal with partially signed messages? Something like that exists? Yes, so here's some ways. If you're using mine, the way the mine structure works is you have a... You say, this is a signed message, and there's one part that's the signed part and there's one part that's the signature, and the signed part itself could, of course, be a multi-part. So the whole message should be signed. But what you can do is you can take that whole signed part and say, oh, this is actually just a subpart of another mine tree. And then your message itself can be a multi-part mix message that has a multi-part signed subpart that itself has a signed body, but then the multi-part mix has another direct child. So your signature actually only applies to a section in the middle of the message. Or encryption. Encryption as well, right? So there needs to be a visual indicator to a user about which part is which. And unfortunately, it's actually quite common for most folks in this room probably to have signed messages a hit shift, but other... Just tell me your password. It's live. Just tell me your password. Stupid security. You can kill all the experience out here or something. I'm sure you can. Especially passphrase. You have to discuss all the dots. So it's actually really common that you get this for signed messages, particularly with Mailman. So when Mailman receives a message, when Mailman is configured to send a footer on the message, if the message that he gets is not a simple text plain message, it takes the existing mind body and it does exactly what we just talked about. It makes the whole message now a multi-part mixed, with the first part being the original message and the second part being the footer, a text slash plain footer. So the signature actually applies successfully to the whole message except for the footer. So you can now arbitrarily inject data at the end of your signed message. I think that the matmail reader actually does a good job at displaying these properties. So it has some bar that says the following text is signed and at the bottom it says end of signed text and then I often see the Mailman footer below the end of signed text tab. It does it in a different styling that is not applicable to regular text. So it seems to be a good solution for displaying that stuff but it doesn't work for OpenSSM. Doesn't work for OpenSSM? S-minus. Why don't you use... Why don't you use GPGSM? Well, if you receive an S-minus signed mail, what do you use? In mat or... In mat. Yeah, it automatically uses GPGSM. Ah, okay. What we're talking about is not much yet. So the point is that the matmail reader does have a way of displaying this which I think is the same. Okay. The news does the same. It also displays a bit of signed message, a signed file and a signed message and it works also nice to keep forward a signed message so that you can see which signature it is. So, I mean, not much Emacs actually has an indented mind part view that allows you to see by indentation and by label where the mind parts enter. My question is, has anybody here tried to attack these to make a message that looks like this? To make it look... To add a header that says the text below is signed and the text above is unsigned that actually has no signature in it and see how it renders in these clients? For GNU's, it's possible because GNU's has switch text support in the form of the old one, the HTML. There are some configurations which have for the HTML and so on. It's really hard to get something in the Emacs window. That's not spoofable. There's a little use Emacs feature called the fringe. I'm not sure if GNU's actually uses that. So the fringe is something at the side of the screen. Which kind of use the fringe to mark parts of the text part? I mean, I think regardless of the Emacs you would have to reserve something like that or whatever as... And we would have, especially because we use the threaded display... We would have to have something reserved that can be rendered any other way. Whether that... You reserve red in the fringe and any time anybody tried to use that, we would convert it to something else. But we would have to escape basically. Right, and then you need to know that this red is the special red? Yeah, and that's hard. If the fringe works, that's not a terrible idea necessarily at all. So... Yeah, and make a reference to Emacs. Oh, here we go. I think this Emacs fringe maybe should go up here. And under something too. Yeah, because of that. Okay. So, I'm going to skip over the scoops I just sent because that's about message composition and that's not much Emacs which I do want to get to that as well because I think that's relevant. But I want to work just for the moment on thinking about the issues with not much as a male reader not as a message composition. So, at the moment we don't deal with messages at all. There's a bunch of reasons for not dealing with in-line PGP because in-line PGP is actually pretty broken. But at the same time some of us are still receiving in-line PGP mail and we have to deal with it. In the in-line PGP signed message we can't, you know, the signature is not verified and an in-line PGP encrypted message you're just going to see a blob of ciphertext. So, one question is what do we want to do about this? Do we want to try to address it in the mail reader? In the user interface when we're doing the decryption for regular PGP mine encrypted messages the decryption happens in not much. So, if we want to be able to do the decryption at the not much layer that we need to add there or maybe the answer is well for in-line PGP we're going to handle decryption at the layer of whatever the these are different options. But currently we're not dealing with in-line PGP at all. Who here uses a not much run-in regularly and also regularly receives in-line encrypted PGP mail? So, what do you all do? Write the You go command line. No! Maybe we can be more specific. I use the not much interface to go pull the raw figure out what the file is so you're using like the X Clipboard or using like from within Emacs or I think it's the thing that allows you to rip a mime into a separate file then I may not be caveman. But I mean we're using the X Clipboard then or we're using What front end? What front end are you using? What do you mean by not much? When you're using not much, is it not much Emacs? Emacs. Okay, so you're in not much Emacs I don't want to realize I have one of these things that drives me nuts, I've dropped a command line to a not much search and just quickly changed context because I've never figured out how to do any of the handle or plain un-inline sign playing. So that's not much not so DECRYPT message or whatever I think that's what it's called DECRYPT tab, tab, tab in not much Emacs So yeah I can DECRYPT region if you first tell not much to show you the wrong mail file then you can run DECRYPT region on it and hope it does the right thing. Unless some mail transfer is in a long way converting everything into its own special base 64. Yeah, in which case Bdale's method is preferable because I think I've struggled in the past I've tried doing things like that sometimes I magically get a useful result but it's rare enough that and the people I'm getting messages from I sort of have this mental pattern of oh all I have to do is and all I have to do is is I can't actually tell you I just have to turn on my own and start typing and it happens. So one useful thing in this context is not much can put the name of the file in x-kill ring with a couple keystrokes so and that then you can take that into an extra and that's a good way to switch context like that. So I can share my dirty tricks for dealing with this. My dirty tricks for dealing with this is that I reply to the message and then I have and then I do whatever my fingers do to highlight the part of the buffer that's the body of the reply and then I have a really simple stupid shell script so that's good that does all the mind parsing stuff to get the keys out where I'm at and then I select the whole thing and I do meta one, meta pipe and I send it through a script that removes the indentation decrypts it re-ads the indentation and adds a whatever the secure like you know please encrypt this outbound message so that I mean in a reply context with the entire body of the message and my reply will automatically be encrypted on the way out. So do you find it at all ironic that you're the person advocating not supporting in-line PGP in not much emails? Or are you misinterpreting your stance? What I want is I want the entire universe to get rid of my PGP. Yeah. I can't do that in this room and I'm just trying to brainstorm here in terms of what's the right way to deal with this and I want to hear what other people's solutions are. I'm not claiming my solution is good. It's a dirty, dirty hack. There is another possibility that starts similar to yours which is that you reply to the message and say, fuck you, send me a message. I'm not reading your bullshit. Don't send me in-line PGP. It's not 1990. That's great. I think we should just convince Enigmail to change its default. Enigmail is changing its default. Enigmail is changing its default. The next version of Enigmail will default to PGP mine. We have already changed the default for Enigmail in Devin. That has solved at least for me most of the problem because it's 99% Enigmail. There are PGG4O users and there is no way for GBG4O to compose PGP mine messages. GBG4O It's a GBG plugin for Outlook. I'm not using it but I'm receiving mail from people to use it. Is it proprietary? Hey. I'm communicating with them. I don't get to tell them what to use. Yeah, I know. I'm communicating with them that PGP mine is in the company and I already did that. Oh, good. Yeah, I don't know whether they will do this. Okay. I was actually asking them whether they knew how to do it and if they didn't, could they point towards the bugs that were in the Microsoft tools that would use it to do it? They say that they support reading PGP mine messages. No, it's not. The main difference is that a PGP mine encrypted message actually contains mine parts on the inside of the encryption and those mine parts that are on the inside of the encryption are if it's a signed encrypted part actually clues it to tell you exactly how you should be interpreting this data. In a PGP inline message this is one of the big issues with PGP inline is that it gets decrypted and now you've got a buffer of decrypted data on how to interpret it and even if that data was signed you don't know how to interpret it because the headers could have been totally spoofed on the outside of the message. So somebody could take the encrypted data and then change the headers and tell you actually this is content type, something or other and then you're going to interpret that buffer of data in a totally different way. Anybody in the ring in the IRC channel national match? Okay, good. Because I sort of suggested that people could ask questions there if they wanted to. Yeah. So what are we going to do? Are we just going to really hope that it all goes away? What's the right thing to do about this? I mean how hard would it be to support in, well you have to have let's thought experiment, how hard would it be to support in the not much CLI that you want to decode of an inline Let's separate signatures, signature verification and decryption. So what if we punt on signature verification and just focus on decryption? How do you handle public hearing and thoughts? I mean that's a similar problem, right? In the sense that you have a PGP block that you have data presence on there. Well that's usually as a separate mind part where there's an attachment that's... people put a the tool has a copy to teleport functionality and they paste it right into your message and you have to get that out there in some way. Yeah, I mean I usually mark and then pipe them I mark and then pipe the region to something that's my usual approach. Yeah, why doesn't that work for decryption? Because decryption provides output that you need to read and import just says yes that succeeded or not. So I mean I do that for decryption sometimes too I mark and import but then you also have you have character encoding issues on the inside right there like oh well maybe this message was quoted printable. You just did your decrypt and now your decryption now the decrypt data is all QP like can you read the QP? I can kind of read the QP depends on you know how fancy the non-asky characters are. It's a mess. If it is like you say that the plain QP wrapper thing has security issues which can't be fixed in that format then it should be deprecated. It is deprecated. The question is what we do with it. It's persistent. Alright. So here's a thought. We all know people that use Windows and compared to inline PGP Windows is a very serious security problem. But we still talk to them. We don't just sort of cut them out of our lives. Well I mean you could. That would be an approach, right? I think that was the suggested approach. Yeah. Right, right. Right. So I'm divorcing you because you use Windows. That's why my wife runs one. Just joking. I really move on because it doesn't sound like anybody has any proposals for how to fix it. Or whether we should fix it. I think that's a question. Or fix it for one and not for the other? Yeah. I think that your proposal for drop signature verification in the UI is a valid thing. You can't necessarily do that with decryption, right? Because then you basically have no communication stream. Right. So if you have to choose between decryption and then your suggestion is perfectly logical. But my suggestion doesn't say how to deal with decryption. I understand that. Yeah. The mind parts that you're parsing, right? If you are not able to deal with decryption now then you just get presented with the crypto text, correct? Yeah. As a mind part. So you put your dirty dirty hack as you put it, right? To do signature verification where you use the reply to function as a way to parse out the mind body. That's what I use for decryption. Oh, that's what you're using for decryption. You could use the same dirty dirty hack as a signature verification as well. Right. So if you do so you have a dirty dirty hack for both of them. It's not pretty but it does work. You end up being able to reply to them. I understand. So I think one of the issues that we at some point wanted to talk about is the interplay between usability and security and in particular by making people jump through hoops to verify inline PGP signatures that means they won't do it. I'm too lazy to do it, right? So I can't expect anybody else to do it. So that's a sort of insecurity vector there. I couldn't agree with you more. So actually we're talking about the security about signature verification. There's another open question which is currently if we can't verify a signature in red. This is a big morning. And I've been thinking about this lately and my inclination is to say that if you can't verify a signature your UI should be exactly the same as if no signature was present. The only indicators that you actually should have for signed mail is this signature was done. We can verify this particular signature and that way the UI of a message that has no signature is exactly as scary as a message that has a broken signature. So if you think that a broken signature is scary you should also think that an unsigned message is scary. And whether that means you want to put a red bar at the top of an unsigned message or not I think we don't because realistically we don't have that scenario. There's a big difference between you don't have that key in your key ring and therefore we can't verify it and this message isn't signed at all. I mean you can go fetch that key and oh now it kind of verifies or doesn't verify or whatever. I think that's an important distinction. Currently it doesn't really distinguish. Red doesn't necessarily say you should go retrieve this key. Sure. But I think there's also a difference between knowing that this message has been tampered with and just knowing but you don't know anything about this. Knowing that it's signed that you can't verify the signature. I mean if the signature doesn't verify it, something must be efficient. So you're saying the UI should indicate a difference between the signature not verifying versus you just not having the key? Yeah, right. Just not having the key I think should be different and also not being saying that oh it should be different. Open PGP signatures don't actually indicate what key they were signed with. They indicate that their indication of what key they were signed with is a 64 bit long key item which is vulnerable to collision attacks and probably vulnerable to premium attacks by it. So it's possible to craft a signature that legitimately says if this particular key ID is signed by this key ID and you have a key that matches that long key ID but it doesn't actually verify there. You can also just forge a signature packet that is meaningless and stuff a key ID that you want the person to fetch into their key or anything and now when they receive the message not much helpfully says hey you don't have the key to solve this thing why don't you pull it into your key ring? So you're creating an attack vector there as well if people believe that the data in their key ring is something that they are conceivably managing in some way that they understand. So it's not a I don't think it's an obvious win either way and I'm not saying that an advanced not much user who really wants to know the details about this particular message should be unable to find out that there was a signature that they couldn't verify but I'm no longer of the belief that a signature that you couldn't verify should definitely be able to handle it. Sorry we're down to 10 minutes left I want to get through some of these. People have ideas about projects they want to work on within not much we're just like kind of spooling out different such problems and some of these because it's so decomposable we're not going to work on it we're not going to get to the breakouts but video team will be happy about it. On the other hand how do other manpower solve the problem with inline signatures because they face the same problems so maybe we can take that out of the conflicts of our discussion not focus on the things that are not much specific I think we should focus on more things but I do think not much has a response to other manpower to solve it by pretending that there is no problem within the signatures and we may not want to solve it in the same way so we're going to go through a couple of other things shell injection terminal escape sequences so this is all I think are related to text rendering like if I send you something and I say hey this is all ASCII text and it includes shell escape sequences is there any way through the code that that could actually get invoked there's a lot of different execs and library calls and what not that happen if anybody testing is not much code base for this kind of attack so it would be great to have some tests to demonstrate at the very least that certain try to be devious think about a way to attack this and see what you can convince out of the tool chain terminal escape sequences are those people's terminal emulators these days don't allow arbitrary code injection but if you cat an arbitrary file to some terminal emulators that terminal emulator will end up executing an arbitrary code and there's a lot of things that how much might do that end up getting dumped to a terminal S-MIME support we don't actually do S-MIME at all we deal with a BGP our S-MIME support is basically absent it's absent largely because G-MIME support is fairly yesterday I got resurrected my old series which does S-MIME signature verification so there's some progress it still has a few rough edges like it's depending on both OpenSSL and GPGSM that can't be the right thing so the EMAT default way to send S-MIME messages for outbound S-MIME messages which I use as part of the test framework in order to have things to see that I can verify them uses OpenSSL and there's an option to use GPGSM which I didn't get working yet but I'm going to try so I know you mixed under EMAT frankly I have all the problems with S-MIME I don't know so I don't really care so I can see I'm not going to get too much work from them which is fair but people do still use this stuff so you're absolutely on point that the problem with encryption is that Jeff Steathouse says well I don't use S-MIME I don't live in this corporate world which seems to be the main place where S-MIME is used but frankly S-MIME is very similar to PGT-MIME as long as it's the modern version and not this old apart thing so I could mention that several times I don't know so I could mention it several times it's really just easy but it's not a huge project it's just a question of I've never written code in G-MIME before so it's a home encode base and so that is a bit awkward so anybody who loves G-Lib such a person exists will like a project well moving on so a couple more things still just focusing on not much as a mail reader there's usability and security question down here we want people to use this stuff we want them to use these secure tools thank you got it so there's a handful of things that actually make it really painful to deal with a mail box that's full of encrypted mail and top among them is encrypted search and after the bunch of encrypted messages not much as interface is searching interface so what am I searching on I basically got only access to the headers that aren't relevant if the thing has been properly encrypted maybe you can search for the date and you can search for the from and maybe if they left the subject in the clear but so my thought is we could make a situation where not much could handle incremental re-indexing so let's assume that my that my index is in a place that is a trusted place it's on my local disk so a message comes in it's encrypted not much index is it it just knows about the ciphertext I'm reading it and my renderer ends up decrypting it for me and as I'm reading it I'm like you know what I would feel comfortable storing the content of this message in my index so just so you know you're not much index is the equivalent of your mail box if you have the index you can reconstruct the messages from your mail box to a first approximation so storing it in the index is the equivalent of storing a clear text version so you could say to your mail user agent index this in the clear and then that would be passed the same message would be passed back to not much with some additional parameters that say hey index it in the clear this time and then not much would decrypt it and index the clear text version and as a result you could search your mail box because you have this message store that doesn't work for messages as they come in before you read them you could configure not much new to say always index your messages in the clear if you really didn't care or if you thought your index was super secure and you wanted to treat it that way so I see people shaking their heads because it seems really scary to store basically a clear next copy of your mail but if you can't access your mail then it's actually not usable and you're going to be discouraged from sending mail and from having people send you a encrypted mail so if we can like the trade off between having a clear text search versus not getting encrypted mail like the security wing is on the clear text search side but you just set up a whole a whole new batch of vectors to attack that mail box store sure but people put that mail box doesn't contain encrypted mail in the other scenario because people just don't bother using it because it's too hard to search I'm just saying I mean I'm not disagreeing with you but if the index is your default mechanism for accessing the information and you're correct but if that's the way you solve that then as an attacker I'm going to identify users that are using not much mail I'm going to then target their index and I'm going to do everything that I can to get into their index and that is going to be the way that I'm going to I mean the community, the entire community is at risk at that point with that solution one thing I've never understood is why this is better than just decrypting the I mean it seems like you're discouraging only sort of unmotivated attackers or something I mean the really simple thing would be just to decrypt the message say that you're unencrypted well that changes though, not much at the moment doesn't modify any of the data so that's my view so that's a major change I wanted to briefly mention this memory whole work that some folks are doing Patrick from Enigmail and a couple of other projects we're working to actually encrypt the message headers for encrypted mail and we're also protecting the message headers in signed mail as well we have a pretty clear way to go ahead with doing that and we have a couple of different mail user agents that are interested in implementing that I'd love to see not much be one of those mail user agents because the fact that the headers are currently not protected by signatures or encryption is one of the reasons that people don't understand how to use encrypted mail so if you're interested in that, come talk to me or I can point you towards more documentation and one last usability thing is as you're, this is for message composition, as you're composing a message you should be able to tell whether you have keys for the people that you're sending the message to and that currently isn't the case as you're going ahead and sending it into Emacs MML mode it goes ahead and does these modifications so if you're into Emacs MML mode figuring out how to do this how to do the key selection as the message is being composed instead of at send time it might be a useful thing so our time is up we didn't even cover half of the stuff that's up there because we were just looking at the message store but the point here is that there's lots of stuff to work on to improve the situation and to discourage it but hopefully we've broken out the different moving pieces and the different problems to the point where you can say oh here's a problem I'm interested in in a part that I feel comfortable working in and maybe you can solve one of these parts because solving any of these pieces or just improving any of these pieces would be a win for everybody using a tool so I think our time is up well, thanks Dan Woodford for doing most of the work too thank you and I too got to get these things fixed so if you've got ideas about how to do it send it to the NotMuchVanList chat on the NotMuch channel I've got some ideas about what to do but I haven't had very little time and don't understand the code base where I'm not doing it myself I really hope that more people can come in and work on that any volunteers, do you want to have any volunteers that can go and they're going to help you get out of public banks? you know what the answer doesn't have to be you solved it, just what does evolution do for us I mean they use GMI do they yeah, I think so I don't know, so could you look at, could you research that yeah, okay, thanks at least one commitment thank you we're getting a chime over message again they need a break