Re: Mailman has mismatched checksums
Dave, The same thing happened to me. I am also running mailman-2.1.25. I pulled the Defaults.py and Defaults.pyc from the package distribution file and did a diff on the pkg files and the installed files and this is what I found. diff Defaults.py /tmp/Defaults.py < DEFAULT_EMAIL_HOST = 'mailman.obfucscated.com' < DEFAULT_URL_HOST = 'mailman.obfuscated.com' --- DEFAULT_EMAIL_HOST = '//' DEFAULT_URL_HOST = '//' My best guess is that some time in the past I changed the variables DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST in the Defaults.py file rather than mm_cfg.py, and the files Defaults.py and Defaults.pyc didn't change when I did a pkg update. Since I have DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST set in my mm_cfg.py file I assume it's safe to reset these variables in the Defaults.py file but I haven't taken the time to test it yet. I hope this helps. Ted Hatfield On Wed, 17 Jan 2018, Dave Horsfall wrote: When trying to get Mailman going (and seeing what looked like several updates in quick succession), I completely cleaned it out, waited a bit for any more updates, installed the package, waited a bit for any more updates, and I was hoping that this would go away: Checking for packages with mismatched checksums: mailman-2.1.25: /usr/local/mailman/Mailman/Defaults.py mailman-2.1.25: /usr/local/mailman/Mailman/Defaults.pyc No configuration whatsoever was done; I merely installed the package and waited for any more updates to arrive. So, what can I do about it? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Procmail got updated!
On Sat, 23 Dec 2017, Matthias Andree wrote: Am 23.12.2017 um 08:12 schrieb Kevin Oberman: So, why does Eugene's question have no relevance to the procmail case? Could you please explain? Because I am not willing to discuss generics when we have a specific case of port at hand. The attempted generalization distracts from that, and I insinuate that distraction is the purpose. Everyone is free to start a new thread about general port maintenance and removal principles. I think the best reason to keep procmail available in ports is that there are still quite a number of people still using it. In fact opensource.com has an article dated 11/01/2017 titled: SpamAssassin, MIMEDefang, and Procmail: Best Trio of 2017 https://opensource.com/article/17/11/spamassassin-mimedefang-and-procmail Not necessarily an argument for code safety but a good argument that it's still being used by quite a number of people. I think that as long as someone is willing to patch the software when vulnerabilities come up we should keep the port available. Ted Hatfield ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Procmail got updated!
On Wed, 20 Dec 2017, Kevin Oberman wrote: On Wed, Dec 20, 2017 at 4:19 PM, Matthias Andree <matthias.and...@gmx.de> wrote: Am 20.12.2017 um 06:40 schrieb Eugene Grosbein: On 20.12.2017 01:03, Matthias Andree wrote: Dear Ted, Eugene, [skip] What happened with old good "Tools, not policy" thing? It's simpler than that, no policy involved. The tool had a hollow head, and broke after several years of banging it, and the former tool maker told the public it's out of warranty (never was in due to it being free) and not being fixed any more, and should be scrapped. It still works (painfully) and is used by many. They would be wise to stop, but it is not the job of the project to force them to do so, I do think that a pkg-message with "Here there be dragons! Proceed at your own risk. dropmail is a MUCH safer (and easier) path." would be appropriate. I don't think it is the job of the project to force people to replace it if they think they know what they are doing. Of course, bitrot or similar may take it before long. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 I still use sendmail/procmail for all of my systems. If it's up to a vote I would vote to keep procmail as a valid port. That being said I am not a port maintainer and I wouldn't presume to tell them what to maintain as I am not the one doing the actual work. However based upon my experience I am betting that there are a lot of systems still out there that are still using procmail. I think if you choose to drop support for procmail you should do as Kevin suggests and give a warning and a firm date when support will stop. This will give people a chance to update their systems appropriately. Ted Hatfield ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Procmail got updated!
On Tue, 19 Dec 2017, Matthias Andree wrote: Am 19.12.2017 um 01:30 schrieb Ted Hatfield: On Mon, 18 Dec 2017, Matthias Andree wrote: Am 18.12.2017 um 00:17 schrieb Dave Horsfall: Doing my regular update, and... Upgrading procmail from 3.22_9 to 3.22_10... Good grief; who's the masochist who volunteered to support this obscure insecure and hitherto-unsupported scripting language? https://svnweb.freebsd.org/ports?view=revision=455800 I'd agree we should pull the plug on the package. We'll be in for the usual "but it works for me" screaming of the irresponsible people who don't care (and most of them won't know that they need to write the exception/error handling themselves in their .procmailrc recipes). Sunpoet, can we mark the port as deprecated given that even the upstream once said it should best be abolished? I can't find the reference now, the procmail.org website displays "Site hosting in transit, information will be back up shortly." Dear Matthias, As one of the "irresponsible" people who is still using procmail on our systems and has built an number of scripts and customer infrastructure around it I take exception to the term irresponsible. Perhaps the better word is overworked. If I had the time to move to dovecot/sieve or maildrop as a local delivery agent I would have done so by now. Ted Hatfield Dear Ted, Eugene, I think if the procmail language were a bit more "regular", someone would have written converter scripts long ago by now. Other than that, I find it hard to believe that people don't have time for over x in [3; 17] years to migrate, which in many cases would in my book be more a situation of "I don't want to..." rather than "I am unable to...". I don't mean to judge your situation, just that to me it looks a matter that you have not yet found it important enough to bother. Given that the former maintainer asked OpenBSD to pull the plug on the port already 37 months ago (see here <https://marc.info/?l=openbsd-ports=141634350915839=2>) after findings from fuzzing, and now to see security updates to a defunct upstream port, I don't think we should keep the port around for much longer. The expiration I was proposing isn't "axe it out now", we would not normally do that, and it's at the maintainer's (i. e. sunpoet@'s) discretion what expiration date, if any, will be set. But the question if we as downstream packagers/providers want to step in for a package abolished by the upstream almost a generation ago, is one that needs serious consideration. I wouldn't endorse that the project waste time on decrepit ports for which decent alternatives exist. Best, Matthias Matthias, My response wasn't meant to disprove your argument. There is a valid case behind dropping support for procmail and you are welcome to make that argument. From my point of view (and I bet quite a few others) I've been using a software product provided by the port maintainers for quite a long time. During that time I've kept my software up to date and patched. As far as I am concerned I've done my due dilligence. If you want to make an argument against maintaining procmail I completely understand that. I just don't think that denigrating others while making your argument is the way to go about it. Ted Hatfield ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Procmail got updated!
On Mon, 18 Dec 2017, Matthias Andree wrote: Am 18.12.2017 um 00:17 schrieb Dave Horsfall: Doing my regular update, and... Upgrading procmail from 3.22_9 to 3.22_10... Good grief; who's the masochist who volunteered to support this obscure insecure and hitherto-unsupported scripting language? https://svnweb.freebsd.org/ports?view=revision=455800 I'd agree we should pull the plug on the package. We'll be in for the usual "but it works for me" screaming of the irresponsible people who don't care (and most of them won't know that they need to write the exception/error handling themselves in their .procmailrc recipes). Sunpoet, can we mark the port as deprecated given that even the upstream once said it should best be abolished? I can't find the reference now, the procmail.org website displays "Site hosting in transit, information will be back up shortly." Dear Matthias, As one of the "irresponsible" people who is still using procmail on our systems and has built an number of scripts and customer infrastructure around it I take exception to the term irresponsible. Perhaps the better word is overworked. If I had the time to move to dovecot/sieve or maildrop as a local delivery agent I would have done so by now. Ted Hatfield ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Alpine mail client discontinued?
A quick google search shows re-alpine http://sourceforge.net/projects/re-alpine/develop http://re-alpine.sourceforge.net/ The continuation of the Alpine email client from University of Washington. Maybe you would like to create a port. Ted Hatfield On Mon, 17 Oct 2011, Marco Beishuizen wrote: Hi, Alpine has been my favorite mail client for years now. Unfortunately the university of Washington is no longer developing Alpine. The current version is 2.00 and isn't updated since 2008. Is Alpine definitely dead or should I look out for an alternative? (Btw I don't know how to program, or I would try this myself). Marco -- Surly to bed, surly to rise, makes you about average. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/mail/procmail Makefile
On Tue, 30 Aug 2011, Matthias Andree wrote: Am 30.08.2011 19:57, schrieb Mark Linimon: On Tue, Aug 30, 2011 at 07:44:12PM +0200, Matthias Andree wrote: It only warns, it does not prevent fresh installs on systems that don't have the same port/package already installed. code, not policy ... ? Well... is _is_ policy and meant as such. We make decisions for ports users all the time, and this is no exception. If procmail has no ongoing security issues and it compiles and installs with no problems what's the reasoning behind removing it from the ports tree? As far as I can see the reasoning advocated at this time is that procmail hasn't been in active development since 2001. Shouldn't that be seen as a sign of stability. I'm not a software developer so maybe I'm missing something obvious about this situation. Feel free to educate/convice me that I should make the effort to switch from procmail to maildrop. I've been using procmail now for 16 years and I'm very happy with it's performance. Moving to maildrop would be a significant amount of effort for both me and my users. Ted Hatfield ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
spamass-milter-0.3.1_9 leaving open zombie processes.
spamass-milter-0.3.0_9 appears to be an update to fix the security
vulnerability referenced by CVE-2010-1132.
However the patch installed for this vulnerability fails to close
processes properly and spamass-milter leaves a large number of zombie
processes open until the milter is restarted.
Rather than wait for the port maintainer to update this port we
installed the patches found at http://savannah.nongnu.org/bugs/?29326
Specifically
file #20020: spamass-milter-0.3.1-syntax.patch
file #20284: spamass-milter-0.3.1-popen.patch
If anyone wants to see tham I have included the patches I used.
Does anyone have an ETA for an official update.
Thank,
Ted Hatfield
PrismNet Ltd.
IO.COM.
--- spamass-milter.cpp 2006-03-23 21:41:36.0 +
+++ spamass-milter.cpp 2010-03-23 16:44:54.570023100 +
@@ -129,9 +129,11 @@ int daemon(int nochdir, int noclose);
static const char Id[] = $Id: spamass-milter.cpp,v 1.90 2006/03/23 21:41:36
dnelson Exp $;
+static char FilterName[] = SpamAssassin;
+
struct smfiDesc smfilter =
{
-SpamAssassin, // filter name
+FilterName, // filter name
SMFI_VERSION, // version code -- leave untouched
SMFIF_ADDHDRS|SMFIF_CHGHDRS|SMFIF_CHGBODY, // flags
mlfi_connect, // info filter callback
@@ -361,7 +363,7 @@ main(int argc, char* argv[])
// }}}
/* Update a header if SA changes it, or add it if it is new. */
-void update_or_insert(SpamAssassin* assassin, SMFICTX* ctx, string oldstring,
t_setter setter, char *header )
+void update_or_insert(SpamAssassin* assassin, SMFICTX* ctx, string oldstring,
t_setter setter, const char *header )
{
string::size_type eoh1 = assassin-d().find(\n\n);
string::size_type eoh2 = assassin-d().find(\n\r\n);
@@ -387,12 +389,12 @@ void update_or_insert(SpamAssassin* assa
if (oldsize 0)
{
debug(D_UORI, u_or_i: changing);
- smfi_chgheader(ctx, header, 1, newstring.size()
0 ?
+ smfi_chgheader(ctx, const_castchar*(header),
1, newstring.size() 0 ?
cstr : NULL );
} else if (newstring.size() 0)
{
debug(D_UORI, u_or_i: inserting);
- smfi_addheader(ctx, header, cstr);
+ smfi_addheader(ctx, const_castchar*(header),
cstr);
}
} else
{
@@ -452,7 +454,7 @@ assassinate(SMFICTX* ctx, SpamAssassin*
if (do_reject)
{
debug(D_MISC, Rejecting);
- smfi_setreply(ctx, 550, 5.7.1, Blocked by SpamAssassin);
+ smfi_setreply(ctx, const_castchar*(550),
const_castchar*(5.7.1), const_castchar*(Blocked by SpamAssassin));
if (flag_bucket)
@@ -470,7 +472,7 @@ assassinate(SMFICTX* ctx, SpamAssassin*
#else
char buf[1024];
#endif
- char *fmt=%s \%s\;
+ const char *fmt=%s \%s\;
FILE *p;
#if defined(HAVE_ASPRINTF)
@@ -500,7 +502,10 @@ assassinate(SMFICTX* ctx, SpamAssassin*
} else
{
// Send message provided by SpamAssassin
- fwrite(assassin-d().c_str(),
assassin-d().size(), 1, p);
+ if (fwrite(assassin-d().c_str(),
assassin-d().size(), 1, p) != 1)
+ {
+ debug(D_COPY, fwrite incomplete (%s)
when copying to spambucket, strerror(errno));
+ }
pclose(p); p = NULL;
}
#if defined(__FreeBSD__)
@@ -531,7 +536,7 @@ assassinate(SMFICTX* ctx, SpamAssassin*
// time. Note, this may generate multiple X-Spam-Orig-To
// headers, but that's okay.
while( !assassin-recipients.empty()) {
- if ( smfi_addheader( ctx, X-Spam-Orig-To, (char
*)assassin-recipients.front().c_str()) != MI_SUCCESS ) {
+ if ( smfi_addheader( ctx, const_castchar
*(X-Spam-Orig-To), (char *)assassin-recipients.front().c_str()) !=
MI_SUCCESS ) {
throw string( Failed to save recipient );
}
@@ -774,7 +779,7 @@ mlfi_envfrom(SMFICTX* ctx, char** envfro
{
SpamAssassin* assassin;
struct context *sctx = (struct context *)smfi_getpriv(ctx);
- char *queueid;
+ const char *queueid;
if (sctx == NULL)
{
@@ -801,7 +806,7 @@ mlfi_envfrom(SMFICTX* ctx, char** envfro
// remember the MAIL FROM address
assassin-set_from(string(envfrom[0]));
- queueid=smfi_getsymval(ctx,i);
+ queueid=smfi_getsymval(ctx, const_castchar *(i));
if (!queueid)
{
queueid=unknown;
@@ -842,7 +847,7
Re: spamass-milter-0.3.1_9 leaving open zombie processes.
On Mon, 10 May 2010, Robert Huff wrote: Ted Hatfield writes: spamass-milter-0.3.0_9 appears to be an update to fix the security vulnerability referenced by CVE-2010-1132. The current ported version appears to be 0.3.1_9? Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org Oops, My bad. typo on my part. I meant 0.3.1_9 as listed in the subject line. Ted Hatfield ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: spamass-milter-0.3.1_9 leaving open zombie processes.
Forgive my ignorance and the long rambling email below. I have limited knowledge of the intricacies of diff and the patching process so I'm not sure exactly what you are asking for when you say Can you perhaps send me a port diff?. Here is a full description of the process I went through to get the milter running on my servers. Because I did not know which patches you had already applied to the port nor where you had obtained them, I determined that I would need to patch a copy of the original source by hand with the patches I found at the savannah.nongnu.org website. I downloaded the original source from the savannah.nongnu.org mirror site. I then applied the two patches I listed below to the original source and verified that it would configure and make properly. These patches can be obtained from http://savannah.nongnu.org/bugs/?29326 file #20020 and file #20284. Once I know that this was working properly I then verified that the distfile the port was downloading was the same as the source I downloaded from the savannah.nongnu.org repository. This convinced me that I could modify the patch files in the /usr/ports/mail/spamass-milter/files folder. Each of the patch files I downloaded from savannah.nongnu.org consisted of a combined diff for the files spamass-milter.cpp and spamass-milter.h. I then separated each individual patch file into separate pieces. I combined those separate pieces together into two new patch files that I used to replace: (note that I said REPLACED) /usr/ports/mail/spamass-milter/files/patch-spamass-milter.cpp /usr/ports/mail/spamass-milter/files/patch-spamass-milter.h Although this new port is running on my servers and it appears to have fixed both the security flaw and the zombie process bug, I'm uncertain if I have opened up any other security hole or bug in the process, because I don't know what other patches you had in place that I removed nor what their purpose was. I sent my original email both as a way of informing the port maintainer of the problem as well as a link to the code that purported to fix the problem, hoping that you would have a better idea of what else I might have broken when I fixed the problem. If you require something from me that I can provide please let me know and I'll do my best to get it to you. Thanks, Ted Hatfield On Mon, 10 May 2010, Niels Heinen wrote: Hi Ted, Thanks for pointing this out! Can you perhaps send me a port diff? (will shorten the ETA) Thanks, Niels On 05/10/10 21:07, Ted Hatfield wrote: spamass-milter-0.3.0_9 appears to be an update to fix the security vulnerability referenced by CVE-2010-1132. However the patch installed for this vulnerability fails to close processes properly and spamass-milter leaves a large number of zombie processes open until the milter is restarted. Rather than wait for the port maintainer to update this port we installed the patches found at http://savannah.nongnu.org/bugs/?29326 Specifically file #20020: spamass-milter-0.3.1-syntax.patch file #20284: spamass-milter-0.3.1-popen.patch If anyone wants to see tham I have included the patches I used. Does anyone have an ETA for an official update. Thank, Ted Hatfield PrismNet Ltd. IO.COM. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Niels Heinen FreeBSD committer | www.freebsd.org PGP: 0x5FE39B80 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
