On 2023-04-19 Adam Thompson wrote:
When Wietse says "don't use procmail" many times over the last... 20? yrs, and then Gilles Chehade (OpenSMTPd) also says the same thing, repeatedly, and then I Allman said the same once when I asked in person, I just stop questioning, because I have better things to do with my time than argue with people far better-versed than I in a particular space.
Still meh. Name dropping doesn't excite me. Ya, might perk my ears up a tad more than nobodies, but many will have an agenda. We all know many *BSD people seem to have a severe NIH complex. And the author of Postfix already has a hate-on for anything sendmail-era right out of the gate. If I find 5 prominent UNIXers that still use procmail, does that make me the winner? It's all rather silly. We've had the exact same discussion about sendmail, and ... and ...
Summarizing it, albeit dated: https://lwn.net/Articles/416901/
I love it, it looks like a Lennart or PHP-voting-majority "argument": ====== The merits of the competing filter-writing syntaxes are a bit subjective, but it is easy to see that procmail's recipe syntax is more terse, using non-alphabetic characters and absolute positioning in place of keywords like "if" and "to." ======
Oh noes, it's terse and a computer person might actually have to learn a new "language" like they do all the time when language-du-jour comes out and they have to tweak code. The horror!
The replacement uses "if" so it must be better! Ya ok, maybe to some kid just starting out, but not (again the whole point) someone who has been using it since 1993.
I find this more convincing: "it is feature complete and apparently pretty bugfree"
as it echoes what I said. Why can't the program just be "good" and "done"? I don't rewrite all my 10 and 20 year old code every few years for kicks just because.
<much tongue-in-cheek, and cheekiness; apologies>
One countervailing point: Procmail starting becoming abandonware as of 2001, in 2014 that was codified (see link, above), BUT apparently it's under maintenance again as of 2020 (although the website is dead-ish, sigh). LOL, even the Wikipedia page says: "For approximately ten years, procmail was not maintained, and multiple serious security vulnerabilities[7] were discovered in the intervening time span[3] (since fixed)."
I followed the rabbit hole and it looks like as bugs were found, people talked about it and distros added patches to the src rpms. Sounds par for the course.
But speak of the devil: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633 scroll to bottom
Someone seems to have taken it over and fixed any recent bugs, including a formail (companion program not used as much) heap overflow. A new version with a new minor number (24) has been released and should worm itself into the distros.
So if the main point is it's "abandonware", then that seems to settle that.
Message #44 in that link is from the original author (van den Berg) himself, and is an interesting read. Especially:
======== What can we learn from this: a. Clearly I had my security focus on procmail back then. But all the critical paths have been audited to pieces before the year 2000. ...
From a statistical standpoint, given the points a) to d) above, I'd say
that procmail/formail have a above average track record and can be trusted. ========
Mic drop?
The only real thing I see in any of the forks' issues pages is handling stuff like UTF8 headers. But in all my time I've yet to see where this is *required*. You can still use procmail regex to match the funky encoded version of whatever header. Ugly, but it works. I have little doubt someone will add support for them into procmail soon, as I'm sure there's pre-existing C libraries to do the conversions, and turning on UTF8 shouldn't be hard (though I do live outside the world of C)?
I'm only saying that when the people with the best credentials in the history of the universe on how to write RFC822-handling software all seem to agree that I shouldn't use procmail, I'm probably going to stop using procmail without demanding they explain their reasoning to me in detail.
Fundamental philosophical differences. I don't listen to any voice of authority asking me to change unless I can do my own exhaustive research and come to my own conclusions. (Hmm, where have we all recently had experiences with this dilemma?) Maybe that's why I rarely change anything, ever! Hah
I'd put more stock in the opinion of MUUGers (including yours) than rando wizzardz (hehe) on the interwebz.
You know that as well as anyone here - 99% of the programs we run on a daily basis aren't "safe" in either a theoretic (academic) or practical sense. GNU added enough features to it that I would think twice before suggesting even cat(1) is safe. But there are varying degrees of safety, and various approaches to it.
But aren't you then ruining your original argument that we shouldn't use procmail because "people" declare it unsafe? So then it becomes a matter of degrees and the level of "convincing" one is subjected to?
If unsafe -> discontinue use, and you just said vim -> unsafe, then you have just said vim -> discontinue use. Have you discontinued use of vim?
Er, say what? Run them on different ports, if they're all internal,
Nope, both sendmail and postfix are external-facing. The requirement is each IP appears to the world as its own box, with no trace or mention of the other (legal-ish privacy-ish reasons). Neither should send/receive through the other's IP. Postfix can do it, sendmail cannot. That was my problem.
You could avoid ssh by running a daemon with appropriate permissions on lo0 and aliasing to "|nc 127.0.0.1 12345".
Yup, I just dreamed up using a named pipe or similar last night. But then I'd still need to root to make sure the daemon auto-restarts if it dies. So not much better off, unless systemd has an unprivileged-user service concept now(? man that would be handy).
I'm not convinced you truly need multiple MTAs in the sense you suggest, but I'm not in your shoes so it's possible - in which case you have my sympathy :).
Ya, trust me, I explored every avenue (short of VMs; though maybe there's a container / jail way?). The pain was great, but the pill has been swallowed so no sense finding a "better" solution now. Well, at least until my sendmail+postfix twinning blows up due to RHEL clamping down on the thumbscrews. But at least I'll have a relatively painfree option of just twinning my postfix config and ditching sendmail (or sendmail will have the outgoing IP configurable by then).
Ohhhh yeah, if you need two different MTAs on the same RH or even Deb-based system, I would recommend installing the 2nd (and subsequent, if any) from source just to avoid having them fight over who gets to be the system MTA on every package update.
Turns out it wasn't a problem. The /etc/alternatives setup and interesting use of options in postfix make it update-proof. At least until we bump up a major RHEL version number. It was quite hard and interesting with no guarantee of success, but it worked 100% in the end with no downsides I can see; besides being insane. If anyone other than me ever wanted to do such a thing (never gonna happen) I'd do a presentation on it. :-) I found zero people actually attempting or accomplishing the feat on the net, so not much help there.
You are possibly the only person I would ever /recommend/ use git! I absolutely believe it's a good fit for your brain! Every time I have to use git for anything non-trivial, though, I am equally-absolutely guaranteed to leave work with a headache at least 3 days in a row, usually more like 2 weeks. If git works for you, great, meanwhile I'll be over here installing RCS.
Oh git still gives me major headaches, whenever I have to do something I haven't done yet and have a thin grasp of how to achieve it. I've learned that you hair-pull for a while to get a new thing done, then save the invocation in your cheatsheet. The grokking part seeps in later.
Remember "crash your system in 2 keystrokes, or less"? Ya, git feels a lot like that; but there's almost always an "out" -- the key is finding it...
I've found the git books (of which I have many) teach you all this stuff about the node graphs and such that turns out to be near useless for actually using the thing to just dev, save and push. Though I guess at some level knowing the guts actually makes the final grokking possible. Hard to say.
I like RCS. But RCS can't possibly do all the git does for me now. You'd probably be impressed (or dumbfounded?): 2 levels of libraries, and app, a "super-app" on top of that app, all with git-subtrees, 2 apps with 4 deployments (dev, test, demo, live) each. Everything is a git push away from having the latest version, including an automated db schema updater. My dev is now warp speed and I spend no time at all on db syncing or deployment. A new app on the libraries can be made in an hour by a clone and adjusting a conf file or two (mostly paths and url prefix). Who used to have the slogan "now you're playing with power".
Sorry to bear this bad news, but yeah, the same behaviour applies for aliases "|" execution.
Damn.
No rationale as yet, but it happens in set_ugid.c: https://github.com/vdukhovni/postfix/blob/master/postfix/src/util/set_ugid.c
Thanks for the link. I love short and sweet source files. There's the lame setgroups in there just staring at me, mocking, doing apparently nothing useful.
it's essentially been there forever. And nary a mention in the HISTORY file about why.
I have faith you'll eventually find the original argument you read a hundred years ago. Gotta be somewhere.
I'm in agreement with you here, it seems unhelpful, so hopefully someone else here can explain why secondary groups are *so* bad for security they need to be nuked from orbit?
That's a great question for all MUUGers to ponder. Maybe someone has an idea. I mean we can all agree the smell (as you say) seems to be on the right track, but here's my real world pain point in opposition to it, as well as upsetting the "don't surprise the user" dictum. Sitting here right now I can't really thing of a really-possible security issue caused by keeping the groups intact. I'll ponder it further in my sleep.
The sendmail people obviously didn't consider this a "bug", unless they really just never thought of it.
As such, if the braintrust of MUUG can't imagine a reason, it may be productive to open a postfix bug/featurereq for it. At least that might make the devs justify the original choice.