> Right now a user can sit down, compose a message that happens to contain
> 8-bit characters, and send it out ... and nmh will happily blast it out,
> with no MIME headers at all. This is super-wrong. And it's not a
> theoretical problem either:
>
> http://lists.nongnu.org/archive/html/nmh-wo
Hi Robert,
> ps: often "easier to audit" means "presumed better" which means
> "investigated less stringently" which leads to "unsafe". There's no
> shortcut to actually doing the work.
The "short-cut" is to have dynamically-growing strings and arrays
generally, and use those in many cases wher
Hi Rickard,
> This is a very treacherous source of embarassment, because you may for
> some time be unaware of the peculiar appearance of your outgoing
> e-mail. I for one don't need my MUA to make me look stupid, I usually
> manage unaided.
You know of the workaround where you alter your initial
Hi!
> You know of the workaround where you alter your initial drafts to have
> hard-coded
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
>
> headers, altered to suit?
Maybe I was half aware of the possibility of such a workaround,
Hi Robert,
Robert Elz wrote on Mon, Dec 16, 2013 at 01:41:19PM +0700:
> Ingo Schwarze wrote on Mon, 16 Dec 2013 06:24:02 +0100:
[...]
>| Well, the warning is not so much about "could" or "might" (in theory),
>| but about *practical* experience of code auditors. It reads:
>|
>| warning: strcat
Ralph wrote:
> Does anyone run the test suite using valgrind(1)? :-)
Yes, actually :-) One of the tests (an important one, on inc)
relies completely on valgrind; it is skipped if valgrind is not
available. Another test can be told to use valgrind.
I manually run valgrind sporadically and have
Hi David,
> > Does anyone run the test suite using valgrind(1)? :-)
>
> Yes, actually :-) One of the tests (an important one, on inc) relies
> completely on valgrind; it is skipped if valgrind is not available.
> Another test can be told to use valgrind.
I was thinking more of every nmh comman
Ralph wrote:
> I was thinking more of every nmh command optionally running under
> valgrind for all the tests.
That's been on my wish list for a while. Patches welcome :-)
The test suite does run every undeprecated nmh command, that's a
start.
David
___
>Don't things like http://www.gnu.org/software/gnulib/ and
>http://gcc.gnu.org/onlinedocs/libiberty/ remove some of the pain of
>common non-POSIX functions, e.g. asprintf()?
Just so everyone doesn't think I'm completey unreasonable ...
I looked at this, and it replaces that pain with some NEW pai
Date:Mon, 16 Dec 2013 14:31:30 +0100
From:Ingo Schwarze
Message-ID: <20131216133130.ga31...@iris.usta.de>
| Again, the intention isn't "every single use is broken", but "almost
| every real-world codebase using it has at least some issues".
That maybe true, but t
On Dec 15, 2013, at 9:12 AM, Jon Steinhart wrote:
> So I'd simply change the attach code to use file --mime and maybe get
> rid of some of the stuff that I originally put in there to create mime
> types from collected information.
'file --mime' is not portable.
signature.asc
Description: Mess
Some meta-commentary regarding this whole thing:
- I've already explained my objection to the strl*() functions, so I won't
repeat them again.
- I'm personally torn between Robert & Ingo's positions: I don't think
sprinkling strlcpy() everywhere is the right answer, but I can't defend
the M
Ken wrote:
> - Really, this overuse of strcpy/strcat results from our usage of fixed
> sized buffers. We should be switching to dynamically-allocated strings
> whenever possible. Fixing that means dealing with idea of who actually
> owns a particular memory object and is responsible for fr
13 matches
Mail list logo
