Hi David,
I hope this strncpy thread doesn't run on for ever and anon.
It's delaying my brace-style email.
> > I dunno, I think we'd need to think carefully if a particular use of
> > strncpy() really warrants an abort vs a truncate. I mean, just
> > crapping out on a really long line that other
Hi Todd,
> Paul Vixie wrote:
> > Copy or die, as the default behavior.
malloc! Or death!
> Both snprintf() and strlcpy() make it fairly easy to detect whe the
> buffer was too small, which is more than I can say for strncpy(). It
> is up to the programmer to actually check the return value.
A
Hi David,
> > I went with the defaults for all but the first prompt.
>
> I should revisit the OAUTH, TLS, and SASL defaults based on what
> configure now does with them.
I found the build on Mac OS X failed. build_nmh prompted `[n]' for TLS,
which I accepted with Enter. That stopped --with-tls
Hi Ken,
> You know, somehow I had missed all of these years that strncpy() pads
> out the rest of the buffer, which is certainly not ideal!
Yes, I keep forgetting it and rediscovering. :-)
> I can only say that on my Linux systems, I don't have strlcpy() or
> -lbsd.
Here it's provided by packa
Hi,
Some of nmh's code uses strcpy(3). That can overflow the destination.
Probably for that reason, some uses strncpy(3), e.g.
char s[BUFSIZ];
strncpy(s, addr, sizeof s);
That avoids the overflow, but s may lack a NUL terminator. So some code
goes one better with
strncpy(s, addr,
Hi,
Some more notes on building at the "bleeding edge" that is Arch Linux.
:-)
ar: `u' modifier ignored since `D' is the default (see `U')
This is due to the new `D' option to ar(1) for deterministic mode.
automake have been told they need to adapt, but have done nothing with a
patch for mon
Hi David,
> Worked well on a machine where I hadn't built it before, but was
> likely to have some of the optional development packages installed.
The second time `sh build_nmh' is run the `git clone' fails because
./nmh exists and isn't empty. The user doesn't know that immediately
though becau
Hi David,
> This now works:
>
> wget http://git.savannah.gnu.org/cgit/nmh.git/plain/docs/contrib/build_nmh
> &&
> sh build_nmh
>
> Good enough?
Worked well on a machine where I hadn't built it before, but was likely
to have some of the optional development packages installed. I went
with th
Hi Ken,
> But to answer [Norm's] question ... the division of labor is kind of
> like the division between show(1) and mhl(1); send(1) takes a message
> and maybe does some minor processing on it (or splits it up), and then
> passes the file off to post(8) to actually send it (post takes a
> filen
Hi,
David spotted some compile warnings that I didn't. I've since
overridden configure's CFLAGS to add `-pedantic -ansi', but I wonder if
m4/cppflags.m4 should attempt these and add them if they work? The risk
is someone has a compiler that spots problems all of ours missed.
That's probably unli
Hi Norm,
> > It looks like it's always the first argument now; seems easy enough
> > to keep that the way it is.
>
> Those two guarantees would make it easier to write a postproc that
> would be robust against changes in post and the way it's called.
So post(1) needs it -whom documenting to make
Hi Tom,
Twas you I saw mentioned. :-)
http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=82f1f1db8de7b833068a3ef0dc7d10759bb94941
That's just been updated to not be generated and use the single identity
array I mentioned. It means a function call instead of probably a
macro, but it disappears,
Hi Tom,
> I've never heard of an implementation not using -1, though.
Me neither, and that's what the code's depending on thus the #error
otherwise. (Would be quite interesting to find such a platform. :-)
> > extern int ctype_identity[257]; /* [n] = n-1 */
> > #define isupper(c) ((isu
Sorry, me again.
> Instead, each look-up table can be a private array with a pointer to
> its second element, and index that. Sound OK?
Thinking about this a bit more. The "generate C at compile time" can be
dropped by
#ifndef NDEBUG
#if EOF != -1
#error "Please report this to nmh'
Hi,
I wrote:
> Back to ctype.h, can we now assume POSIX
ISTM that the sbr/ctype-checked.h versions assume, wrongly, that
isdigit(EOF) and tolower(EOF) aren't valid, for example, and will index
an array with -1. We can't increment all the indexes by one as that
will promote a char to int before t
Hi Ken,
> > and then a check or distcheck shows up problems from earlier edits.
>
> I kind of thought for efficiency's sake we shouldn't build things that
> we don't need. It just seems wasteful to me build all of the test
> suite programs when they're not used; I guess the thinking there is
> th
Hi Ken,
> - The real problem isn't the tight loop for script(1); it's that when
> this version of script gets an EOF on the "user" side (because the
> input is set to /dev/null)
I'm not sure why script(1) is run in the background and then immediately
wait'd for; is it to just get https://plus.go
Hi,
Ken wrote:
> I noticed that test/install-mh/test-version-check is hanging for me on
> MacOS X. Specifically, the "script" command on MacOS X seems to be
> the problem; for reasons I don't understand quite yet when "script" is
> run the input is set to /dev/null
I've found a Mac Mini I can SS
Hi Tom,
> All of these solutions presuppose that this is my problem and not the
> software's. I respectfully disagree.
Me too. :-)
There's a mechanism for telling a hierarchy of programs their locale;
environment variables. You're using it, but you're telling some of them
a different locale t
Hi Tom,
If you just have one long-running Emacs then can't that be in the UTF-8
locale? Or is your C-needing ls(1) run from inside that?
Have Emacs highlight non-ASCII characters in that mode wherever they
come from, e.g. paste from web browser? Have a function that maps the
common ones to ASCI
Hi,
Ken wrote:
> And if we're voting ... I would rather have only one additional way to
> specify a nmh-specific locale (well, I'd rather have ZERO additional
> ways, but I think more than one way is overkill).
I'd rather have zero. :-) Anything above that surely warrants an
nmhlocale(1).
> (A
Hi Ken,
> > Valid UTF-8 and valid GB2312 can share the same sequences,
> > especially if it's just the odd `£' or `拢` in ASCII text.
>
> It was just a suggestion, not one I was particularly crazy about ...
> but not all arbitrary 8-bit sequences are valid UTF-8.
Oh, agreed.
> And it looks like f
Hi Ken,
> Personally, I like it in the main repo, but I don't feel strongly
> about it either. Maybe we could put it on a branch, with everything
> else trimmed out of the repo? That way if anything else "historic"
> showed up we could add it to the branch.
Whatever would be most useful for you
Hi Laura,
> Just giving them utf-8 even though that wasn't what they asked for has
> fixed a huge number of headaches when running mailing lists around
> here.
Does that mailing-list software check that what they're sending out is
valid for the encoding they claim, UTF-8? Or when replying to an
Hi David,
> > I've noticed things like test/fakepop only get built on a `make
> > check' because that needs to use them. OTOH, it would be nice to
> > see compilation succeeds along with everything else in the `all'
> > target.
>
> Maybe add a phony target that would build the test programs?
Yes
Hi Tom,
> But I don't really agree with the tradeoff that's been made of failing
> when you can't be sure of that.
I don't think nmh should be complicit to you putting an RFC-invalid
email onto the wire; there's enough of them in the world already. :-)
> Especially since, if you think you know
Hi Ken,
> I just have a hard time adding a switch to send (or really, any nmh
> utility) when there's already OS-supported mechanism for overriding
> the locale for individual commands by changing the environment
> variable.
I'm surprised whatnow(1) hasn't grown the ability to prefix the command
Hi Ken,
> > (3) assume charset=utf-8 (maybe allow this to be overridden in
> > profile)
>
> We already do (1) and (2). (3) is the problem. Other people who have
> thoughts on this topic are free to weigh in. Personally, I believe
> that if you're doing LANG=C, you shouldn't be dealing with any
Hi,
Seems a bit odd to be mailing nmh-workers with actual "worker"
content... I've noticed things like test/fakepop only get built on a
`make check' because that needs to use them. OTOH, it would be nice to
see compilation succeeds along with everything else in the `all' target.
I've been buildi
Hi David,
> This message draft has In-Reply-To: and References: header lines,
> introduced by the default replcomps. How would those lines get
> through post?
nmh would learn that those are in the directive set, like `To', and
`Attach', and ideally something about their RFC format too so it can
Hi Daivd,
> Is "user having to add to that list" in your original proposal?
Yes, one of the copies.
> Is it a profile entry to allow the user to add known header names?
I think I suggested a profile entry for their common ones, e.g. Ken's
X-Face, and a send(1) option for the ad hoc to whatnow(1
Hi Paul,
> i was starting to think i was done with this, but i guess i'm not.
Rather that re-tread worn ground, how about a considered reply to my
suggestion that all headers be known to nmh and the user having to add
to that list, or pass it as the value of a `wire' header. :-)
http://lists.non
Hi Norm,
> While developing and debugging a postproc, I want to use nmh to send
> mail without using the postproc that I'm debugging, but to use it
> sometimes when I do a send.
Keep toggling the name of the postproc entry?
sed -i '/^x*postproc:/!n; s/^x/y/; s/^p/xp/; s/^y//' .mh_profile
--
Hi,
I wondered if any thought has been given to capitalisation in man pages
of commands, etc., that are case senstive. I think if a sentence starts
with `send', for example, and is talking about send(1) rather than the
English word, then it should be lowercase as /usr/bin/Send is a
different prog
Hi Ken,
> I don't think we talked about it, but way back when I first posted
> that script there was general discussion about how that was a pain and
> (I believe prompted by you, actually) I fixed that in commit
> 4857e59b250f2.
Rings a bell. Looking again at the script, it's the -whom detectio
Hi,
David wrote:
> See docs/README.developers.
Thanks, that helped quite a bit. I've pushed a trivial fix to master.
If I've done anything wrong, e.g. not configured my ID properly, then
let me know.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Hi,
Norm wrote:
> Would you be willing to tell me how, in such a script, I could detect
> the presence or absence of a specific header, say "Exception: norm"?
So, thanks to the other replies, Norm's happy taking Ken's
http://lists.nongnu.org/archive/html/nmh-workers/2016-10/txthpshEQcPNr.txt
and
Hi David,
> Great! We'll get you to the bleeding edge yet.
:-) Through a cunning bit of social engineering the other day, I did
apparently gain access to nmh's git repository. Is there anything that
documents conventions in using it for the project, e.g. whether to check
in directly on master
Hi David,
> Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38 have fixed
> this?
Yes, indeed. I get identical output from iconv(1) and mhshow(1) with
the function from
http://git.savannah.gnu.org/cgit/nmh.git/tree/uip/mhshowsbr.c.
> + if (errno == EINVAL) {
> + /* midd
Hi again,
> 1.6's mhshow(1) says
>
> mhshow: unable to convert character set to gb2312, continuing...
I meant to draw attention to that. It was converting *from* gb2312 (to
UTF-8).
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
Nmh
Hi,
I got an email recently, probably spam, its charset is gb2312.
$ mhlist
msg part type/subtype size description
8032 text/plain 10K
charset="gb2312"
$
1.6's mhshow(1) says
mhshow: unable to convert character set to gb2
Hi,
kre wrote:
> Rather, I usually delete [X-Mailer] as I consider it no-one else's
> business which software I use
Yes, I'd want to turn it off from that point of view too. I use mail(1)
for short internal emails, and here it's provided by package s-nail
which had a series of different core-dum
Hi Ken
> I admit I am not clear where Ralph stands on this particular issue;
> perhaps the Marmite shortage is affecting things :-)
Marmite's basic ingredient is yeast sludge, a waste product from brewing
beer. Give me the beer. It's solely produced in Burton, which used to
have a large beer-br
Hi Paul,
> > No, I mean "Subjct: Nice to see you again" isn't embarassing; I
> > always intended they'd see the header's value. "Bc: myboss,
> > yourboss", is. And "Atach: /home/ralph/pita-client/foo" is as
> > normally they'd only see "foo".
>
> but there's no solution, to this, right? we can
Hi Ken,
> > If they're are mistyped Attach, Bcc, or Dcc then they could be
> > embarrassing?
>
> Well ... sure? But I think that's an issue with any header name.
No, I mean "Subjct: Nice to see you again" isn't embarassing; I always
intended they'd see the header's value. "Bc: myboss, yourboss
Hi Ken,
> I realize that sounds harsh, but I am trying to understand why leaking
> those headers would be harmful.
If they're are mistyped Attach, Bcc, or Dcc then they could be
embarrassing?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_
Hi Ken,
> > Incompatible change, I realise. Just trying to step back a bit and
> > see why we ended up here.
That was more explaining my meanderings rather than asking the question.
:-)
> There are a couple of things going on here. One is, like you said,
> headers tell nmh programs what to do.
Hi Paul,
> > In case my point was missed: the Attach: header was not scrubbed
> > out.
>
> sure, but that's a bug. and (i think) we could catch those bugs with
> a test script.
I don't have the relevant switch to have Attach processed automatically
so it getting through isn't a bug, and I might
Hi Norm,
Ken wrote:
> Traditionally there have been a lot of these "internal" switches used by
> programs to pass down information between various (n)mh programs. We've
> slowly been documenting them; we haven't got them all.
I just ran
strace -fe execve -o /tmp/st comp
here, with `w', the
Hi Paul,
> as i understand it, the only worry with not using an Nmh- prefix is
> with leaking headers. since none of these are supposed to ever get
> out, conscientious scrubbing should get rid of them.
Headers in a draft are being used for two things. Directives to nmh,
and verbatim headers to
Hi David,
> > > Can't we redirect standard input on it to provide the command?
> >
> > I doubt it.
>
> Right, the script man page on some systems cautions against doing
> that.
Actually, thinking about it, it probably would work in this case.
> > I think the test is mhparam(1)'s checking for a T
Hi Oliver,
> Just two failures left:
> usage: script [ -a ] [ typescript ]
...
> This is a new check with the welcome message stuff. Judging from
> online man pages for script, this will have problems on other systems
> too. OpenBSD for example, only seems to have a -a option for script.
> Ca
Hi Paul,
> > tolap=$(whom $draft | grep ' at laptop\.org')
> > fromfox=$(formail -c -x From: < $draft | egrep '@foxharp\.')
> > if [ "$tolap" -a "$fromfox" ]
>
> Not likely to be a problem here, but "x$tolap" protects from tolap
> starting with a `-'. But then each needs t
Hi Paul,
> i'll post my script here, because i always learn something when ralph
> corrects my scripts. ;-)
:-)
> if egrep -q '^(To:|Resent-To:)[[:space:]]*$' $draft ||
> ! egrep -q '^(To:|Resent-To:)' $draft
-i for insensitive?
Factor? `^ *(Resent-)?To *:'. Helps the reader and
Hi Norm,
> I usually have a line, 'n...@dad.org', in my drafts. I do that instead
> of something like 'fcc: inbox', because I want to see what my Email
> looks like after it has gone through the net.
Me too. I use `dcc: ralph'.
> But sometimes I forget to otherwise address the message.
I forge
Hi,
$ pick -seq lp all
42 hits
$ pick -seq lp notlp
pick: sequence lp full
$ echo $?
1
$ pick lp
42 hits
$
It's a wart that one can't inverted a sequence that's `full'. (I don't
think the error message is tremendously clear.) I know sequence's can't
be empty,
Hi Ken,
> > I think that buf may only be len long on occasion when the NUL is
> > added.
>
> So could we get a Ralph-ified version? I think the necessary
> configure glue should be straightforward, but someone else will have
> to test it. I'd be glad to commit it, though.
I've written a getline
Hi Ken,
> ...Gmail is kind of a dominant player. And it's clear from the stuff
> I've read online that people with much more clout than I have tried,
> and the people in charge of Gmail simply Don't Give a Shit.
>
> Again, it sticks in my craw that we have to do this, but all
> indications are th
Replying to myself,
> BTW, RFC 2822 defines Bcc, including that it can remain in the sent
> email with no values to indicate to the non-blind recipients that
> blinds were sent.
And other programs, like sendmail, handle Bcc headers so that's a case
where MH's use does blot out another's use.
> S
Hi,
I think there's a difference between nmh headers the user might
typically add manually in a draft, e.g. Bcc, and those that are more the
mechanics of something they drive another way, e.g. Attach and the
whatnow prompt. (Will the new Forward grow a `forward' whatnow(1)
command in time BTW?)
Hi Paul,
> adding the "Nmh-" prefix would create the very first such header. as
> i understand it, we already have 4 nmh-specific headers: Resent,
> Forwarded, Replied,
Those are all added only if -anno is used for each of those commands.
They don't appear in a draft?
> and Attach. i don't se
Hi Oliver,
> https://sf.net/p/gar/code/HEAD/tree/csw/mgar/pkg/reprepro/trunk/files/0004-implement-missing-getline-function.patch
>
> Any good?
Sorry for not replying earlier. I had a look. It uses fgets(3) so has
to use strlen(3) to find out how much was read, but that fails for
"foo\0bar\n".
Hi Paul,
> > > +1. The `Forward' header is grabbing another one for nmh's use,
> > > in addition to the existing `Attach'. Should we be using
> > > `Nmh-Forward' if the user isn't likely to have the hassle of
> > > typing them most of the time?
> >
> > Sigh. I think when we hashed this out las
Hi David,
> I haven't looked at the getline() replacement. Are you [Oliver] going
> to do that? Your Makefile.am and configure.ac changes look good to
> me.
I've written a getline based on getc(3) and
https://manned.org/getdelim.3p. I'll test it a bit more and send it on.
It's only a fallback;
Hi Ken,
>mhbuild will still handle #forw directives in case someone wants to
>have exact control over their message content.
o/
> 4) After 1.7 comes out, Jon Steinhart will send a message to
> nmh-workers asking why forw doesn't work anymore :-) (I'm sorry, I
> couldn't resist).
After
Hi Norm,
> If I understand you, you are proposing to do, what you said yesterday, was
> very difficult.
No, I think he's just turning `forw -mime' into plain `forw', and
removing the need for running `mime' at the whatnow prompt. So it's
more automatic for the common need.
--
Cheers, Ralph.
ht
Hi Norm,
> > 1) You have asked to send someone all of the attachments from a
> > particular message. That functionality is not native to nmh, but it
> > is possible to script it.
>
> But what I don't understand is why isn't it? In fact, why isn't that
> an option to forw, or even its default?
Hi Laura,
> But I get them in the order they arrived. I want them in the order
> they were sent, which can be a whole lot different, before I read
> them.
Use sortm(1) on the sequence, e.g. `sortm .-last'. Or am I
misunderstanding? (Don't run `sortm' without arguments by mistake as it
defaults
Hi Oliver,
> A number of tests are failing on Solaris. This seems to mostly consist
> of:
> id: illegal option -- u
> Usage: id [-ap] [user]
> FAIL: test/mhmail/test-mhmail
http://git.savannah.gnu.org/cgit/nmh.git/tree/test/post/test-post-common.sh#n12
suggests the effective user ID is only
Hi David,
> I get this for one example:
>
> [ part 2 - application/pdf - Statement.pdf 4.4KB (suppressed) ]
I get MIME type and Content-Description, if there is one.
Is that `4.4KB (suppressed)' part of the C-D?
> But then, I'm using nmh 1.6 :-)
Me too! 1.6-3 on Arch Linux. Ubuntu 10.10
Hi,
Regarding the
[ part 2 - application/postscript - foo.ps ]
that appears when viewing an email, has any consideration been given to
looking up a `summary' command for the MIME type/subtype, falling back
to type, in the same vein as mhshow-show-* profile entries?
There's quite a bit of me
Hi Krn,
> > Content-Type: inode/x-empty; name*=UTF-8''%41%00%42
> > Content-Disposition: attachment; filename*=UTF-8''%41%00%42
>
> Sigh. We use a lot of C strings, so we're not so great on handling
> embedded NULs. It's one of those things that is simultanously hard to
> fix, and AFAICT
Hi Earl,
> > If not a tty, we're back to the question. Safer to fail, friendlier
> > to decode.
>
> Decode. How often are real files with "=?...?=" in their name them
> encountered?
If you other recent email you said "If we are to be security conscience"
and I think that's the right default sta
Hi David,
>If the server doesn't support 8BITMIME, fail with a message to user
>that they need to encode the message for 7-bit transport. That
>would be a change from current nmh behavior.
Current behaviour being it spots top-bit-set bytes and QPs or base64s?
As someone that pays for
Hi Ken,
> I don't think you're understanding the problem. There are no invalid
> octets here; the issue is whether or not we perform an automatic
> decode.
But now Lyndon's brought it up,
Content-Type: inode/x-empty; name*=UTF-8''%41%00%42
Content-Disposition: attachment; filename*=UTF-
Hi,
Valdis wrote:
> Ken wrote:
> > I think we're all fine with that; I'm wondering if we should see if
> > it's an RFC 2047-encoded filename and just decode it automatically.
I think my -1 has already been counted.
> I see plenty of sources of heartburn if somebody sends a filename with
> Hebrew
Hi Ken,
> David says:
> > I think it would be a good idea to change it. Ralph is right,
> > multiple From headers bypass the check for missing Sender in post.
> > Multiple addresses in one From header
>
> I see your point; I didn't really understand that was really what
> Ralph was asking about.
Hi Ken,
> > Would it be more useful to demand From be a single header in the
> > draft, though still allow that one header to have multiple
> > addresses? That would catch the accidental sending of a
> > multiple-From draft due to editing woes whilst still allowing
> > multiple From addresses.
>
Hi,
nmh merges multiple address headers, e.g. From, To, CC, DCC, in a draft
into one. For most of them, that seems fine. For From, which is
required in a draft these days, multiple From headers are probably not
intended? It's valid by RFC 5322, 3.2.6, as long as Sender is then
present, but unco
Hi Lyndon,
> Ken wrote:
> > First, I see plenty of intro man pages around that provide pointers
> > to more details, so there is prior art.
Two examples are perlintro(1) and gittutorial(7). That first one is a
good example of a high-level skim and taste of using Perl.
https://manned.org/perlintr
Hi David,
> It doesn't happen if stdin or stdout isn't connect to a terminal
So both have to be to a TTY. Perhaps stderr, where the welcome appears,
should be too? Otherwise a `2>/dev/null' in someone's script might
throw it away.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Hi Ken,
> RFC 2047 encoding is ALSO used when you attach a filename with 8-bit
> characters when you use the web interface for Gmail. If you Google
> "rfc 2047 vs rfc2231" you can get an idea of what happened (Chrome and
> Thunderbird support it for decode, and Google uses that as
> justification
Hi Oliver,
> Could we perhaps include a configure test and a fallback
> implementation such as the one below
I realise it's probably just the first one that came to hand, but it
whiffs a bit, and
> if (buf) {
> buf[len] = '\0';
> }
I think that buf may only be len lo
Hi Ken,
> Well, I just looked; Jerry Peek's original MH book is now under the
> GPL. So we can crib from that I think, as long as proper attribution
> is given. I am not aware of others? There's the original RAND/UCI
> documentation as well, but I don't know how relevant that is.
It was the RA
Hi
Paul wrote:
> Lyndon wrote:
> > As David mentioned, splitting the documentation out from the code is
> > a recipe for disaster. It's not going to happen.
>
> nobody said the local man pages would go away, and nobody said the
> online copy of documentation would be the only copy.
Right. This
Hi Ken,
> I believe we are available via the package systems on a number of
> modern Linux variants.
Would visitors benefit from a list of package names for the popular
systems? Perhaps on http://www.nongnu.org/nmh/ so they see there's not
much of a hurdle to trying it out, compared to building
Hi Mark,
> > If it's a simple package install then I'm not too surprised. I
> > often find myself on others' machines without root access and put in
> > a request for a raft of useful packages. The local admins skim
> > through the list, see they're all straightforward command-line
> > stuff, e.
Hi David,
> > any reason we couldn't in principle have a separate git tree on
> > savannah just for "compiled" man pages, and other docs?
>
> Is there really a need?
Well, I suppose if http://www.nongnu.org/nmh/ could point visitors to
something that looked like https://manned.org/nmh.7, perhaps
Hi Ken,
> I kind of think that the days of nmh being installed on centrally
> managed systems is slowly coming to an end.
If it's a simple package install then I'm not too surprised. I often
find myself on others' machines without root access and put in a request
for a raft of useful packages.
Hi David,
> > This is one place where I would like a link to documentation, at
> > some master site, (so you can read it even if the docs never made it
> > to where they are supposed to be for your distro.)
>
> Unfortunately, there isn't such a site. If the man pages didn't get
> installed, that'
Hi Jeff,
> What would be good to find is a script that can do an audit of a
> system's ca-certificates and list any that have been revoked or have
> expired and run this on our build servers.
Go has a good set of crypto stuff in its standard library, done by
Google's Adam Langley who's one of the
Hi Jeff,
> Debian ARM (Rasbian, C.H.I.P) sadly show a last update of 2014.
:-(
It's not quite that bad. Debian stable is Jessie, and it has
ca-certificates 20141019+deb8u1 which you'd think was 2014, but
http://metadata.ftp-master.debian.org/changelogs//main/c/ca-certificates/ca-certificates_20
I wrote:
> Consisdering very long-term users, and new users,
I meant to mention a barmy idea about dropping a "welcome" email on the
unsuspecting. I think things like Gmail do this and understand
"onboarding" is the vulgar vernacular.
It could point them at nmh(7), the web site for news of relea
Hi Ken,
> Hey, should we be checking CRLs as well? I ask, because at work the
> CRLs I have to deal with have only 5 million certificates on them ...
>
> In seriousness, I wonder how often client software does that? I know
> OCSP responses can be cached, but still ...
wget(1) has --crl-file. O
Hi,
Laura wrote:
> For instance, I was blissfully unaware of this mailing list and that
> nmh was ever under active development until a few years ago, and I
> suspect that there are quite a few others out there who are still in
> this position.
Consisdering very long-term users, and new users, nm
Hi,
Back to OpenSSL, this armchair-Google expert thinks it looks like
OpenSSL may provide certificate-chain verification?
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
N
Hi Ken,
> A brief survey suggests to me that common open-source systems do not
> ship a set of popular commercial root certificates.
I thought they all did. On a couple of machines to hand.
$ pacman -Qs certificate
local/ca-certificates 20160507-1
Common CA certificates (default
Hi
Tom wrote:
> OpenSSL... don't seem to particularly care about ABI compatibility.
Idly, http://www.libressl.org/ is one alternative, aiming to improve the code
quality amongst other things. It includes a new libtls "designed to
make it easier to write foolproof applications" as well as "libss
Hi rfg,
I have a SMTP server on the Internet that accepts the email and holds
it, ready for fetchmail(1) to run at home and pull it down to hand to a
local SMTP server that plonks it in a spool file for nmh's inc(1) to
read. You could probably cut out some of those parts with nmh's more
recent fe
Hi Ken,
> Geez, Ralph, we're never going to make you happy, are we? :-)
Re-write in Go? :-)
> I think you know the answer to this one: obviously the code that does
> the Re: stripping doesn't know about RFC-2047 encoding. Fixing this
> given current nmh architecture would be hard. I think onc
901 - 1000 of 1614 matches
Mail list logo
