Re: nmh 1.8?
>I would think that finding two plain text files with the same MD5 >that a mail message receiver finds an acceptable read is rather >unlikely though. (Just generally speaking. CRUX Linux for >example uses signify for package checksums, but still generates >MD5 checksums as a fallback. CRC32 is also used still, but noone >would claim it is secure.) I don't doubt accidential collisions are unlikely even with MD5. But it gets back to the core question ... what are you trying to accompish, EXACTLY? If you're the only one sending out Content-MD5 headers and no one verifies them (the default in older versions of nmh was to neither generate nor verify them), then you have no MD5 hashes to verify on incoming emails, nor is anyone verifying the ones you send out. So what, exactly, is the purpose of it? If the cost of keeping it around was low I wouldn't care so much. But the implementation was buried deeply in the MIME encoding and decoding routines. The long-term cost was high. If there is something I am missing about this, please, let me know! --Ken
Re: nmh 1.8?
Ken Hornstein wrote in <20221228151732.bd63b1d2...@pb-smtp20.pobox.com>: ... |MUA that generates that header or checks it. I'm not even sure we |calculate the digest correct for text types, it was a mess in terms |of implementation, _and_ MD5 is Officially Considered Broken. Calling ... I would think that finding two plain text files with the same MD5 that a mail message receiver finds an acceptable read is rather unlikely though. (Just generally speaking. CRUX Linux for example uses signify for package checksums, but still generates MD5 checksums as a fallback. CRC32 is also used still, but noone would claim it is secure.) Have a good slip/slide. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: nmh 1.8?
>> Seems like they should maybe emit warnings for a release > >Yes, i.e. be deprecated. But that ship has sailed and I don't think Ken >would be pleased if I added them back in so they could be deprecated. Sigh. Ralph, you and I don't agree on Content-MD5, which is fine. But I have to point out that as far as I can tell nmh is (was) the only MUA that generates that header or checks it. I'm not even sure we calculate the digest correct for text types, it was a mess in terms of implementation, _and_ MD5 is Officially Considered Broken. Calling the removal of it a security flaw seems ... well, inaccurate at best. Also, that header specified a hash algorithm, not an HMAC, so even if the algorithm wasn't broken it wasn't keyed so an attacker could simply modify the header to match the modified content. From my perspective making -check/-nocheck a NOP has roughly the same security properties as implementing Content-MD5. I'm fine with removing the flags completely so people are forced to remove those flags from config files, or leaving them as NOPs. As I've said before, if there are arguments FOR Content-MD5, I'm willing to hear them. But here's what I said when I removed it and I think everything in there still stands: https://lists.nongnu.org/archive/html/nmh-workers/2019-07/msg00106.html Ralph, I know you said that you think it's useful to check to see if messages get mangled or corrupted, but if you're the only one who generates or checks that header then I don't see how that will work. I think Content-MD5 was just something that wasn't thought out very well when it was created. (I do want to implement S/MIME and real GPG support at some point, which would actually be useful and have some real security properties, but ... sigh, lack of time). --Ken
Re: nmh 1.8?
ralph wrote: > Hi Paul, > > > > - The generation and verification of Content-MD5 headers is no > > > longer performed. The -check and -nocheck switches to various nmh > > > programs that would control this functionality still exist, but > > > are non-functional and will be removed in the next release. > > > > > > That it not deprecation. The user who thinks the MD5 is being > > > checked is being fooled by them silently becoming a no-op. They > > > should be removed so the user instead suffers an error and learns > > > of the change. I'll try to get this done. > > > > Removing the options entirely doesn't seem like deprecation either. > > No, it's not. But it's better than the introduced security flaw. > > > Seems like they should maybe emit warnings for a release > > Yes, i.e. be deprecated. But that ship has sailed and I don't think Ken > would be pleased if I added them back in so they could be deprecated. > Agreed. I can't think of a compelling argument against simply removing the options -- as long as the removal is well-noted in the release notes and man pages -- since the fix is simply removing the options from one's scripts. (Right?) (At the risk of overkill, could the removal also be noted in the "This is a new release of MH" message" that happens after an upgrade? It's been so long since I've seen it :-), I can't really remember how/when that works.) paul =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 22.1 degrees)
Re: nmh 1.8?
Hi Paul, > > - The generation and verification of Content-MD5 headers is no > > longer performed. The -check and -nocheck switches to various nmh > > programs that would control this functionality still exist, but > > are non-functional and will be removed in the next release. > > > > That it not deprecation. The user who thinks the MD5 is being > > checked is being fooled by them silently becoming a no-op. They > > should be removed so the user instead suffers an error and learns > > of the change. I'll try to get this done. > > Removing the options entirely doesn't seem like deprecation either. No, it's not. But it's better than the introduced security flaw. > Seems like they should maybe emit warnings for a release Yes, i.e. be deprecated. But that ship has sailed and I don't think Ken would be pleased if I added them back in so they could be deprecated. -- Cheers, Ralph.
Re: nmh 1.8?
ralph wrote: > --- > DEPRECATED FEATURES > --- > > - The generation and verification of Content-MD5 headers is no > longer performed. The -check and -nocheck switches to various nmh > programs that would control this functionality still exist, but > are non-functional and will be removed in the next release. > > That it not deprecation. The user who thinks the MD5 is being checked > is being fooled by them silently becoming a no-op. They should be > removed so the user instead suffers an error and learns of the change. > I'll try to get this done. Removing the options entirely doesn't seem like deprecation either. Seems like they should maybe emit warnings for a release, but given the limited usefulness of the feature, I'm not sure why we'd bother. In fact, here we talked about adding warnings, but Ken pointed out that we didn't need to, since you read the mailing list. ;-) https://lists.nongnu.org/archive/html/nmh-workers/2018-07/msg5.html =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 21.2 degrees)
Re: nmh 1.8?
Hi David, > Greetings as we approach the new year. Yes, hello all. Hope you've had a nice Christmas. > What does everyone think of pushing out a 1.8 soon? +1 > Here are changes since 1.7.1: > https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes --- DEPRECATED FEATURES --- - The generation and verification of Content-MD5 headers is no longer performed. The -check and -nocheck switches to various nmh programs that would control this functionality still exist, but are non-functional and will be removed in the next release. That it not deprecation. The user who thinks the MD5 is being checked is being fooled by them silently becoming a no-op. They should be removed so the user instead suffers an error and learns of the change. I'll try to get this done. -- Cheers, Ralph.
