Re: nmh 1.8-1 Ubuntu package for Jammy Jellyfish
On Sun, 01 Oct 2023 00:32:46 +0900, Christophe Prévotaux writes: >Would it be possible to get a package for Ubuntu Jammy Jellyfish which is an >LTS ? not unless ubuntu provides backports, which it doesn't seem to. >I saw there is support for the very latest Ubuntu release ( Mantic >Minotaure) but I wonder why no backport is available for Jammy. i'm the person packaging nmh for debian, from where ubuntu just copies the packages for direct inclusion and use. apparently that process is totally robotic, and there doesn't seem to be any human involvement in curating/managing nmh in ubuntu - i'm certainly not involved, even though the package page lists me as maintainer. you'll have to get in touch with whoever in ubuntu does backports. besides that there's always the option of rebuilding the package yourself; nmh's build-dependencies are easy to satisfiy in just about any linux distro released in the last 10 years. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ In German "invent-a-new-word-where-a-perfectly-good-one-already-exists" is probably a word. -- Peter da Silva signature.asc Description: Digital Signature
Re: nmh 1.8 -- repeated Welcome message unless there is a context change
Ken wrote: > unfortunately (we probably should do better at making sure the context > is updated when we display the welcome message). Done, added context_save() immediately after each context_replace() that updates the Version identifier. context_save() can safely be called multiple times, and it only rewrites the disk file if needed. commit 82b04d3149939661608b1ea8764d873c005f9956 Author: David Levine Date: Sat Mar 11 10:03:02 2023 -0500 Save context immediately after adding or updating its nmh Version. To prevent repeating the nmh welcome message if a command fails. Thanks to Mark Bergman for reporting that with inc(1). :100644 100644 d6319939 91e582f4 M docs/pending-release-notes :100644 100644 6b400f2f 69eb879b M sbr/utils.c :100755 100755 07188e9e aca8890c M test/install-mh/test-version-check David
Re: nmh 1.8 -- repeated Welcome message unless there is a context change
>I see that nmh commands are reading the $MHCONTEXT file, parsing the >line "Version: nmh-1.7.1" and printing the Welcome message, but not >updating the file unless there is a context change: In your .mh_profile you can put: Welcome: disable To disable the version checking completely. There's not a wonderful way of dealing with this if you are shuffling around contexts, unfortunately (we probably should do better at making sure the context is updated when we display the welcome message). --Ken
Re: nmh 1.8-RC3?
>> Has anyone tried 1.8-RC3 on a BSD platform? If good, any objection to >> releasing 1.8 soon? > >Unless there's an objection or discovery of a problem, I'd like to >release 1.8 this weekend. Just a minor note: I tested nmh 1.8-RC3 on MacOS X (which I know was already tested) but I also tested GSSAPI/TLS support for sending/receiving (TLS was tested with OpenSSL 3). Works fine! I see no reason to not release 1.8. --Ken
Re: nmh 1.8-RC3?
Simon wrote: > I did some really basic testing (scan, show, repl) on NetBSD x86 > as well as a "make check" and got: > > == > All 112 tests passed > (7 tests were not run) > == Thank you! It really helps to have the NetBSD coverage. David
Re: nmh 1.8-RC3?
Hi David, David Levine wrote: > I wrote: > > > Has anyone tried 1.8-RC3 on a BSD platform? If good, any objection to > > releasing 1.8 soon? > > Unless there's an objection or discovery of a problem, I'd like to > release 1.8 this weekend. I did some really basic testing (scan, show, repl) on NetBSD x86 as well as a "make check" and got: == All 112 tests passed (7 tests were not run) == Cheers, Simon.
Re: nmh 1.8-RC3?
I wrote: > Has anyone tried 1.8-RC3 on a BSD platform? If good, any objection to > releasing 1.8 soon? Unless there's an objection or discovery of a problem, I'd like to release 1.8 this weekend. David > https://download.savannah.nongnu.org/releases/nmh/nmh-1.8-RC3.tar.gz
Re: nmh-1.8-RC2 issues
I wrote: > DaveF wrote: > > > Is this a deliberate decision or a regression? If it is a deliberate > > decision > > it should probably be documented in the NEWS and/or Changelog. I added am explanation for the removal of the par/fmt from mhn.defaults to NEWS. Thank you for pointing this out! David
Re: nmh-1.8-RC2 issues
DaveF wrote: > I have built RC2 on my Gentoo Linux system. It mostly works. The tests all > pass. Thanks! > However. I have noticed that in 1.7.1 etc/mhn.defaults.sh searches for > external programs par and fmt and iconv. If it finds them it outputs > entries for, eg. mhbuild-convert-text: > which use said programs in the pipeline. > > In 1.8-RC2 the programs are searched for and shell variables textfmt and > charsetconv are assigned assigned accordingly, but the shell variables are > not used so the programs are not used in the processing pipelines. There is some unused code in there. (I don't think charsetconv has ever been used.) The helper applications have evolved over time. The use of par/fmt in the mhbuild-convert-text directives turned out to not be necessary. The resulting mhn.defaults from 1.7.1 and 1.8 RC2 should be similar otherwise. > Is this a deliberate decision or a regression? If it is a deliberate decision > it should probably be documented in the NEWS and/or Changelog. The ChangeLog does capture these changes, though maybe not explicitly. I don't think the raw changes are significant enough to be called out in NEWS. > Also, while rummaging about I noted that nmh-1.8-RC2/SPECS/nmh.cygport > contains > VERSION=1.7 > RELEASE=2 > > Don't know if it is relevant, but it seems anomalous. Yeah, that's an example. I don't know if cygport supports shell expansion, if it does it could be changed to resemble nmh.spec. I'll try to look at some point. David
Re: nmh 1.8?
az wrote: > debian: 1.8RC1 builds fine, and all tests pass. (there are, as always, > a small number of debian-specific deltas/patches but nothing of note.) Thanks! > i'll upload that version to debian unstable later today. If you haven't done that yet, I'll be pushing out 1.8RC2 shortly. David
Re: nmh 1.8?
On Sun, 15 Jan 2023 13:47:16 -0500, David Levine writes: >Has everyone had a chance to try out nmh 1.8RC1? I'd like to hear of >results from the BSDs, especially. debian: 1.8RC1 builds fine, and all tests pass. (there are, as always, a small number of debian-specific deltas/patches but nothing of note.) i'll upload that version to debian unstable later today. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Politicians are like diapers. They should be changed often, and for the same reason. signature.asc Description: Digital Signature
Re: nmh 1.8?
Has everyone had a chance to try out nmh 1.8RC1? I'd like to hear of results from the BSDs, especially. For RedHat and Fedora users, you can install it using: sudo dnf install nmh --enablerepo=updates-testing I know that we want to try to get in Andy Bradford's patch for inc with POP and long lines. In any case, I'd like to push out an RC2 given that there have been a few (very minor) code updates. David
Re: nmh 1.8?
Thus said Ralph Corderoy on Mon, 02 Jan 2023 13:21:16 +: > > > Has anyone had a chance to review my proposed changes to inc to be > > > able to handle long lines from POP sources? > > Is the latest in Git? I doubt it. I sent an updated patch but never heard about it making into Git. It would be nice if I could find some time to add some test cases for it, but I didn't have as much time during the holidays as I thought I would: https://lists.nongnu.org/archive/html/nmh-workers/2022-11/msg00028.html As I said in that posting, I've been running a similar patch against 1.7.1 on my system and haven't encountered any problems using it. Andy
Re: nmh 1.8?
On Mon, 02 Jan 2023 12:23:54 +, Ralph Corderoy writes: >> Is anyone here packaging nmh as part of a .deb file in the process of >> testing? > >Alexander Zangerl is Debian's packager in the past; I'm CC-ing him. ...and i still am, but i was out of town w/o net access over the holidays. i'll package 1.8 within a week or so. >I assume if we grabbed the debian directory, e.g. >https://sources.debian.org/src/nmh/1.7.1-12/debian/, then we could have >a stab at building the .deb on a Debian machine; I have one to hand. generall you would have to grab the *.dsc and the *.debian.tar.xz, besides the actual upstream (= your) tarball. the combo of the above is guaranteed (by debian policy) to create pretty much exactly the deb in the debian distro (except for file signatures). >I've had a look at the Lintian output and fixed a spelling mistake. >It also says debian/control could do with a Homepage definition: >Alexander, it's https://www.nongnu.org/nmh/ > >That README also mentions a quick overview of what's shipping what >version: > >A useful overview of what third parties are shipping which release >is available at https://repology.org/project/nmh/versions with a >quick overview on the Badges tab which shows >https://repology.org/badge/vertical-allrepos/nmh.svg. > sure can do; i'll have a look at those as part of packaging 1.8. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Programming is like sex: One mistake and you're providing support for a lifetime. -- ? signature.asc Description: Digital Signature
Re: nmh 1.8?
Ralph Corderoy wrote: > Hi Andy, >> > Has anyone had a chance to review my proposed changes to inc to be > >> able to handle long lines from POP sources? > Is the latest in Git? I see the ‘andy-long-line-patch’ at > http://git.savannah.nongnu.org/cgit/nmh.git/refs/ with one commit: > http://git.savannah.nongnu.org/cgit/nmh.git/commit/?h=andy-long-line-patch=08dffe5aba9563ff06e82d2a8e6a6d746223d10f I pushed that in, and it's not the latest patch, I don't think.
Re: nmh 1.8?
Hi Andy, > > Has anyone had a chance to review my proposed changes to inc to be > > able to handle long lines from POP sources? Is the latest in Git? I see the ‘andy-long-line-patch’ at http://git.savannah.nongnu.org/cgit/nmh.git/refs/ with one commit: http://git.savannah.nongnu.org/cgit/nmh.git/commit/?h=andy-long-line-patch=08dffe5aba9563ff06e82d2a8e6a6d746223d10f -- Cheers, Ralph.
Re: nmh 1.8?
Hi Kevin, > Is anyone here packaging nmh as part of a .deb file in the process of > testing? Alexander Zangerl is Debian's packager in the past; I'm CC-ing him. The end of docs/README.developers says Keep an eye on Debian's packaging, especially what patches they have to apply, and the results of their Lintian checker, which even includes spelling errors in man pages and binaries. https://sources.debian.net/src/nmh/1.6-16/debian/patches/ https://lintian.debian.org/full/a...@debian.org.html#nmh Perhaps some nmh developer that uses Debian, or Ubuntu?, could provide package-building commands, including lintian(1), for Makefile.am so Lintian's complaints are known before release. I assume if we grabbed the debian directory, e.g. https://sources.debian.org/src/nmh/1.7.1-12/debian/, then we could have a stab at building the .deb on a Debian machine; I have one to hand. I've had a look at the Lintian output and fixed a spelling mistake. It also says debian/control could do with a Homepage definition: Alexander, it's https://www.nongnu.org/nmh/ That README also mentions a quick overview of what's shipping what version: A useful overview of what third parties are shipping which release is available at https://repology.org/project/nmh/versions with a quick overview on the Badges tab which shows https://repology.org/badge/vertical-allrepos/nmh.svg. -- Cheers, Ralph.
Re: nmh 1.8?
>Has anyone had a chance to review my proposed changes to inc to be able >to handle long lines from POP sources? While it's not common (most big >email providers like Hotmail, Gmail, etc, all conform to RFCs), there >are occasional emails (mostly from online web stores with shoddy >software) that do send out non-conforming emails. Oof, that fell off of my personal radar. But yes, we totally should get that in for 1.8. --Ken
Re: nmh 1.8?
Thus said David Levine on Sat, 31 Dec 2022 22:00:04 +0100: > Do you or anyone else have anything else you'd like to put in before > starting the 1.8 release cycle? Has anyone had a chance to review my proposed changes to inc to be able to handle long lines from POP sources? While it's not common (most big email providers like Hotmail, Gmail, etc, all conform to RFCs), there are occasional emails (mostly from online web stores with shoddy software) that do send out non-conforming emails. Thanks, Andy
Re: nmh 1.8?
>I just did an upgrade at home to MacOS X Ventura; let me make sure the >test suite passes and there are no obvious issues there. Oof, wait. I just did a "make distcheck" and I get: depbase=`echo uip/mhical.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ cc -DHAVE_CONFIG_H -I. -I../.. -g -O2 -Wall -Wextra -MT uip/mhical.o -MD -MP -MF $depbase.Tpo -c -o uip/mhical.o uip/mhical.c &&\ mv -f $depbase.Tpo $depbase.Po clang: error: no such file or directory: 'uip/mhical.c' clang: error: no input files I just committed a fix. --Ken
Re: nmh 1.8?
Is anyone here packaging nmh as part of a .deb file in the process of testing? I used to routinely do that for .rpm packages, but no longer find myself on a system where that makes sense. Thanks. On Mon, Dec 26, 2022 at 3:48 PM David Levine wrote: > Greetings as we approach the new year. > > It's been a long time since nmh 1.7.1 was released, March 2018 to be > specific. What does everyone think of pushing out a 1.8 soon? Here > are changes since 1.7.1: > > > https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes > > While Ken has a worthy wish list at > https://lists.gnu.org/archive/html/nmh-workers/2019-05/msg0.html > and maybe more, I've reached the point where I don't think that we > should hold up a release any longer. > > What triggered this? I finally figured out how to package for Red Hat > EPEL 8 and 9. I don't think that should be done with 1.7.1. And, the > current HEAD has been stable for a while. As always, new features and > improvements can be added as they're ready. > > Question: is anyone besides me using the Gmail integration on the > gmailapis branch? It needs a fix, but if no one else is using it, > that can wait. > > David > >
Re: nmh 1.8?
>>Do you or anyone else have anything else you'd like to put in before >>starting the 1.8 release cycle? > >I just did an upgrade at home to MacOS X Ventura; let me make sure the >test suite passes and there are no obvious issues there. I just did that, and it builds fine and passes the test suite fine. I _can_ think of things I'd like to get in before 1.8, but I'd rather not hold things up. I say, "Start the engines!" --Ken
Re: nmh 1.8?
>Ralph, your last round of changes look good to me. HEAD builds and >tests cleanly for me on Fedora, Solaris 11, and Cygwin. > >Do you or anyone else have anything else you'd like to put in before >starting the 1.8 release cycle? I just did an upgrade at home to MacOS X Ventura; let me make sure the test suite passes and there are no obvious issues there. --Ken
Re: nmh 1.8?
Hi David, > HEAD builds and tests cleanly for me on Fedora, Solaris 11, and > Cygwin. Good to hear. I had a ‘All 118 tests passed’ with 1.7-branchpoint-884-gf116eb31 when doing ‘NMH_VALGRIND=1 VALGRIND_ME=1 make check’ on a friend's quicker PC running Manjaro. > Do you or anyone else have anything else you'd like to put in before > starting the 1.8 release cycle? Nothing which should hold it up. I'm dabbling with mh-chart.man and the bash-completion generation at the moment, fixing a little bit of degradation, but it way well not meet the cut and that wouldn't bother me. -- Cheers, Ralph.
Re: nmh 1.8?
Ralph, your last round of changes look good to me. HEAD builds and tests cleanly for me on Fedora, Solaris 11, and Cygwin. Do you or anyone else have anything else you'd like to put in before starting the 1.8 release cycle? David
Re: nmh 1.8?
Hi Ken, > Sigh. Ralph, you and I don't agree on Content-MD5, which is fine. The issue is not the repeated distractions of only I used the options or what was the point of them anyway. It's that functionality was deleted but at the same time documented as deprecated and the options left in as no-ops so users wouldn't cotton on. The better path given your opinion would have been to take a stand, delete the code and the options and say it's just tough on the users. That's effectively where we are now as I've removed the options and lingering documentation. -- Cheers, Ralph.
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.
Re: nmh 1.8?
>Greetings as we approach the new year. > >It's been a long time since nmh 1.7.1 was released, March 2018 to be >specific. What does everyone think of pushing out a 1.8 soon? Here >are changes since 1.7.1: > >https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes > >While Ken has a worthy wish list at >https://lists.gnu.org/archive/html/nmh-workers/2019-05/msg0.html >and maybe more, I've reached the point where I don't think that we >should hold up a release any longer. Yeah, I'm with you. I even have some small fixes but ... I don't have the free cycles right now. So my vote is "yes". --Ken
