On 2014/12/29 22:22, Stuart Henderson wrote:
On 2014/12/29 10:14, Stuart Henderson wrote:
lockfile also needs handling (see my earlier mail in
the thread for more details).
Diff and attached port to split off lockfile. Yes there are
alternatives to this, e.g.
On Sun, Dec 28, 2014 at 22:18, Antoine Jacoutot wrote:
On Sun, Dec 28, 2014 at 02:09:24PM +0100, Stefan Sperling wrote:
On Tue, Nov 18, 2014 at 12:42:37PM -0800, Philip Guenther wrote:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for
On Mon, Dec 29, 2014 at 03:55:37AM -0500, Ted Unangst wrote:
On Sun, Dec 28, 2014 at 22:18, Antoine Jacoutot wrote:
On Sun, Dec 28, 2014 at 02:09:24PM +0100, Stefan Sperling wrote:
On Tue, Nov 18, 2014 at 12:42:37PM -0800, Philip Guenther wrote:
Executive summary: delete the procmail
On 2014/12/29 03:55, Ted Unangst wrote:
On Sun, Dec 28, 2014 at 22:18, Antoine Jacoutot wrote:
On Sun, Dec 28, 2014 at 02:09:24PM +0100, Stefan Sperling wrote:
On Tue, Nov 18, 2014 at 12:42:37PM -0800, Philip Guenther wrote:
Executive summary: delete the procmail port; the code is not
On 2014/12/29 10:01, Landry Breuil wrote:
And it came back since then as net/wireshark...
Yes but only after they split packet capture (root) off to a separate
process than the dissectors.
On 2014/12/29 10:14, Stuart Henderson wrote:
lockfile also needs handling (see my earlier mail in
the thread for more details).
Diff and attached port to split off lockfile. Yes there are
alternatives to this, e.g. sysutils/flock (which is somewhat common
on Linux), but
On Tue, Nov 18, 2014 at 12:42:37PM -0800, Philip Guenther wrote:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
It's still in ports. Has it not been deleted for a particular reason?
On Sun, Dec 28, 2014 at 02:09:24PM +0100, Stefan Sperling wrote:
On Tue, Nov 18, 2014 at 12:42:37PM -0800, Philip Guenther wrote:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
It's still in ports. Has it not
On Wed, Nov 19, 2014 at 07:09:28AM +0100, Stephane Tougard wrote:
I do not even imagine my life without procmail, I use it since 20 years,
it's kind of basic Unix tool, documented and used everywhere ...
Is it not possible to find a new upstream maintainer for such an
important piece of art
Stefan Sperling, 19 Nov 2014 09:08:
Code (no matter how old) riddled with security bugs should be removed
if nobody steps up to fix them. Philip doesn't want to step up. I don't
want to step up (I still use procmail at the moment but I'd rather look
for better alternatives). You don't want to
On 2014-11-18 Tue 22:01 PM |, frantisek holop wrote:
Philip Guenther, 18 Nov 2014 12:42:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
just for the record, what is the alternative
you would recommend?
$
On 11/19/2014 01:09 AM, Stephane Tougard wrote:
I do not even imagine my life without procmail, I use it since 20 years,
it's kind of basic Unix tool, documented and used everywhere ...
Is it not possible to find a new upstream maintainer for such an
important piece of art than just try to
On 11/19/2014 03:47 AM, frantisek holop wrote:
but even then, i think the port should not be removed.
most of the software in ports has bugs, so what.
So what?
Well, for starters, procmail runs on the (rather large) POSIX family of
systems. It may not run on all members of the POSIX family,
On 2014/11/19 07:09, Stephane Tougard wrote:
I do not even imagine my life without procmail, I use it since 20 years,
it's kind of basic Unix tool, documented and used everywhere ...
Is it not possible to find a new upstream maintainer for such an
important piece of art than just try to bury
Landry Breuil writes:
On Tue, Nov 18, 2014 at 10:01:33PM +0100, frantisek holop wrote:
Philip Guenther, 18 Nov 2014 12:42:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
just for the record, what is the
On Tue, Nov 18, 2014 at 10:32:58PM +0100, Landry Breuil wrote:
On Tue, Nov 18, 2014 at 10:01:33PM +0100, frantisek holop wrote:
Philip Guenther, 18 Nov 2014 12:42:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
Hi
I'm away next week but I can make a release when I get back.
On Wed, Nov 19, 2014 at 01:27:38PM -0500, Bryan Steele wrote:
On Tue, Nov 18, 2014 at 10:32:58PM +0100, Landry Breuil wrote:
On Tue, Nov 18, 2014 at 10:01:33PM +0100, frantisek holop wrote:
Philip Guenther, 18 Nov 2014
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
As people may know, I was the upstream maintainer of procmail back in the
late 1990's though 2001.
Recent fuzzing efforts have found several bugs in procmail. I was
Philip Guenther, 18 Nov 2014 12:42:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
just for the record, what is the alternative
you would recommend?
-f
--
we must believe in free will. we have no choice.
On Tue, Nov 18, 2014 at 10:01:33PM +0100, frantisek holop wrote:
Philip Guenther, 18 Nov 2014 12:42:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
just for the record, what is the alternative
you would recommend?
Landry Breuil, 18 Nov 2014 22:32:
On Tue, Nov 18, 2014 at 10:01:33PM +0100, frantisek holop wrote:
Philip Guenther, 18 Nov 2014 12:42:
Executive summary: delete the procmail port; the code is not safe and
should not be used as a basis for any further work.
just for the record, what
I do not even imagine my life without procmail, I use it since 20 years,
it's kind of basic Unix tool, documented and used everywhere ...
Is it not possible to find a new upstream maintainer for such an
important piece of art than just try to bury it ?
I would do it if I was anything near good
22 matches
Mail list logo
