Norman Shapiro | 5 Apr 19:28 2008

Alas, No nmh in RedHat 4

It seems that somewhere between RedHat 9 and RedHat 4 (Red Hat Enterprise Linux
WS release 4 (Nahant Update 6)), nmh disappeared. I can't find "nmh" on any
of the RedHat rpm disc images,

I cannot live without nmh!

So I will have to install it myself. Is there an appropriate nmh.rpm for RedHat
4 somewhere?

If not, are the right sources to use

        nmh-1.2.tar.gz

        from

        http://download.savannah.nongnu.org/releases/nmh/

    Norman Shapiro
    798 Barron Avenue
    Palo Alto CA 94306-3109
    (650) 565-8215
    norm <at> dad.org

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Peter Maydell | 5 Apr 20:11 2008
Picon

Re: Alas, No nmh in RedHat 4

Norman Shapiro wrote:
>If not, are the right sources to use
>
>        nmh-1.2.tar.gz
>
>        from
>
>        http://download.savannah.nongnu.org/releases/nmh/

That's now really quite old. I think you're probably better
off taking the current head of CVS, which you can get with:

 cvs -z3 -d:pserver:anonymous <at> cvs.savannah.nongnu.org:/sources/nmh co nmh

Ideally we ought to do another release at some point. Does anybody
remember how to do one? :-)

I happen to have some spare time, which I could use to work out
whether there are bugs in the bug tracking system which ought to
be fixed, fix them, etc, if these are likely to get into a release...

-- PMM

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Parker Jones | 5 Apr 19:24 2008
Picon

RE: Alas, No nmh in RedHat 4


----------------------------------------
> To: norm <at> dad.org
> Subject: Re: [Nmh-workers] Alas, No nmh in RedHat 4
> From: pmaydell <at> chiark.greenend.org.uk
> Date: Sat, 5 Apr 2008 19:11:08 +0100
> CC: nmh-workers <at> nongnu.org
> 
> Norman Shapiro wrote:
> >If not, are the right sources to use
> >
> >        nmh-1.2.tar.gz
> >
> >        from
> >
> >        http://download.savannah.nongnu.org/releases/nmh/
> 
> That's now really quite old. I think you're probably better
> off taking the current head of CVS, which you can get with:
> 
>  cvs -z3 -d:pserver:anonymous <at> cvs.savannah.nongnu.org:/sources/nmh co nmh
> 
> Ideally we ought to do another release at some point. Does anybody
> remember how to do one? :-)
> 
> I happen to have some spare time, which I could use to work out
> whether there are bugs in the bug tracking system which ought to
> be fixed, fix them, etc, if these are likely to get into a release...
> 
> -- PMM
(Continue reading)

Josh Bressers | 5 Apr 20:59 2008
Picon

Re: Alas, No nmh in RedHat 4

> 
> Not too fussed about obscure bugs personally, core functionality seems fine=
>  to me.  Apologies to those for whom it's not the case.
> 
> I'm more concerned about nmh dying.  If people have to compile from source,=
>  there's a reasonable chance they won't bother.  I'd love to see up-to-date=
>  rpm and deb packages get included in the common repositories (redhat/ubunt=
> u/etc).  This would probably be the best way to bring in new users in my op=
> inion.
> 

It's in Fedora at least (I maintain it there).  I don't ever expect nmh to
be in Red Hat Enterprise Linux, as they only have a finite amount of
engineering power, and there is certainly not enough demand for nmh.

The easiest way to get nmh running on RHEL4 is going to be this:

Download this:
http://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/nmh-1.2-20070116cvs.4.fc9.src.rpm
(it's the Fedora 9 nmh source rpm)

Run:
rpmbuild --rebuild nmh-1.2-20070116cvs.4.fc9.src.rpm

At the very end you should see something like this:
Wrote: /usr/src/redhat/RPMS/i386/nmh-1.2-20070116cvs.4.i386.rpm

Just install that rpm.

--

-- 
(Continue reading)

Joel Uckelman | 5 Apr 21:54 2008

Re: Alas, No nmh in RedHat 4

Thus spake Parker Jones:
> 
> I'm more concerned about nmh dying.  If people have to compile from source,=
>  there's a reasonable chance they won't bother.  I'd love to see up-to-date=
>  rpm and deb packages get included in the common repositories (redhat/ubunt=
> u/etc).  This would probably be the best way to bring in new users in my op=
> inion.
> 
> Cheers,
> PJ

There's definitely an RPM of nmh for Fedora (that's where the copy I'm
using right now came from). I don't know who maintains it, but you can
install it using yum.

--

-- 
J.

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Peter Maydell | 5 Apr 22:01 2008
Picon

Re: Alas, No nmh in RedHat 4

Joel Uckelman wrote:
>Thus spake Parker Jones:
>> I'm more concerned about nmh dying.  If people have to compile from source,=
>>  there's a reasonable chance they won't bother.  I'd love to see up-to-date=
>>  rpm and deb packages get included in the common repositories (redhat/ubunt=
>> u/etc).  This would probably be the best way to bring in new users in my op=
>> inion.

>There's definitely an RPM of nmh for Fedora (that's where the copy I'm
>using right now came from). I don't know who maintains it, but you can
>install it using yum.

Debian has an nmh package too; but it's only 1.2 (plus debian patches).
I think that provided that nmh is actually released reasonably often,
the distributions will pick up the new releases so they're more widely
available.

-- PMM

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

pmaydell | 5 Apr 23:52 2008
Picon

nmh vs mktemp()


I've been looking at fixing the various insecure uses of mktemp()
in the nmh codebase. I've gradually realised that although some of
them are fixable, some are really very tricky. The trouble is that
much of the code assumes that you can create a temporary file and
then later on reopen it by name[*]; and often this happens by a
very indirect route, with a tempfile name being passed into
functions which might also be using normal message files. Or we
might create a tempfile and then rename it to something else.

So I think that it might be better to sidestep the whole issue
by just having nmh create its temporary files in ~/Mail. Because
this directory isn't writable except by the user, there's no
danger of malicious attackers creating symlinks in it as there
is with putting files in /tmp/. Some work would still be
required, but nowhere near as much.

Opinions?

[*] if you're not convinced that this is broken even if we avoid
the simple mktemp() race condition, you can find fuller details here:
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILES

-- PMM

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

(Continue reading)

Nick Rusnov | 6 Apr 00:36 2008
X-Face
Picon

Re: nmh vs mktemp()

On Sat, Apr 05, 2008 at 10:52:05PM +0100, pmaydell <at> chiark.greenend.org.uk wrote:
> 
> I've been looking at fixing the various insecure uses of mktemp()
> in the nmh codebase. I've gradually realised that although some of
> them are fixable, some are really very tricky. The trouble is that
> much of the code assumes that you can create a temporary file and
> then later on reopen it by name[*]; and often this happens by a
> very indirect route, with a tempfile name being passed into
> functions which might also be using normal message files. Or we
> might create a tempfile and then rename it to something else.
> 
> So I think that it might be better to sidestep the whole issue
> by just having nmh create its temporary files in ~/Mail. Because
> this directory isn't writable except by the user, there's no
> danger of malicious attackers creating symlinks in it as there
> is with putting files in /tmp/. Some work would still be
> required, but nowhere near as much.

I have to agree that this is a good solution short of massive code changes. I
believe that users can currently do this by setting their TEMP variable to a
directory that they control, but a systematic use of a temporary directory specially
for nmh seems like a good policy. Something like ~/Mail/.temp or some such so as
not to interfere with a potential folder called temp.

--

-- 
-><- Nick Rusnov
-><- http://nick.industrialmeats.com
-><- nick <at> fargus.net/nickrusnov <at> debian.org 

_______________________________________________
(Continue reading)

Peter Maydell | 6 Apr 01:54 2008
Picon

Re: nmh vs mktemp()

Nick Rusnov wrote:
>On Sat, Apr 05, 2008 at 10:52:05PM +0100, pmaydell <at> chiark.greenend.org.uk wrote:
>> So I think that it might be better to sidestep the whole issue
>> by just having nmh create its temporary files in ~/Mail. Because
>> this directory isn't writable except by the user, there's no
>> danger of malicious attackers creating symlinks in it as there
>> is with putting files in /tmp/. Some work would still be
>> required, but nowhere near as much.
>
>I have to agree that this is a good solution short of massive code changes. I
>believe that users can currently do this by setting their TEMP variable to a
>directory that they control

Nope. The code hardcodes /tmp/...

>, but a systematic use of a temporary directory specially
>for nmh seems like a good policy. Something like ~/Mail/.temp or some such so as
>not to interfere with a potential folder called temp.

I thought about having these files be in a subdir, but we'd have to create it
(and hope it isn't used by a user for something already), and it just seemed
to me that it would be easier to put it all in ~/Mail. Judging by some of 
the things I have in Mail/ it looks as if mhshow might be putting temp files
there already...

-- PMM

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
(Continue reading)

Joel Reicher | 6 Apr 07:45 2008

Re: Alas, No nmh in RedHat 4

> Ideally we ought to do another release at some point. Does anybody
> remember how to do one? :-)

There's a target called "nmhdist" in the Makefile (once you've
generated that using the autoconf tools). Ultimately it uses the
string in the file VERSION, IIRC, but I think it's the autoconf tools
which read that in.

> I happen to have some spare time, which I could use to work out
> whether there are bugs in the bug tracking system which ought to
> be fixed, fix them, etc, if these are likely to get into a release...

I think the first step should be to create a 1.3 branch in CVS and then
do the release work on that. There are some changes I've been keeping
to myself because they're a bit too radical to go into the next release,
I think, and if we branched I'd be able to check them into the trunk.

After branching we could generate a 1.3 release candidate. I suggest
the string "1.3-RC1" go into the VERSION file (on the 1.3 branch).

Cheers,

	- Joel

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

(Continue reading)


Gmane