ports/29137: Brand New Tripwire-2.3.1 Port (fwd)

[Cy Schubert - ITSD Open Systems Group]

In message <97665.999162430 at axl.seasidesoftware.co.za>, Sheldon Hearn 
writes:
> 
> 
> On Thu, 30 Aug 2001 01:51:31 MST, "Crist J. Clark" wrote:
> 
> > But weren't you the one who posted the reasons, and they are valid
> > reasons, why there are different ports?
> 
> Um, I doubt it.  If I am, I need a holiday. :-)

Actually I was the one to identify the reasons.  Let me state them 
again.

When I created the tripwire 1.3.1 port approximately 2 years ago, it 
was suggested that it replace 1.2.  I suggested that it wasn't a good 
idea because the 1.2 license is more open than 1.3.1 license.  Hence if 
one could live with a more restrictive license one would have the 
bugfixes.

Tripwire version 2 made considerable changes to the config file format. 
 The issues are,

1.  2.3.1 fixes a serious memory management problem with version 1 which
    limits the number of files that can be monitored before you see 
strange
    things like abends and flagging of files that have not changed.

2.  2.3.1 is GPL.

Ideally, if there is no requirement for to support users with the old 
config file format, then replacing the two version 1 ports with a 
version 2 port would be best.  Given that there might be users of 
Tripwire version 1 who cannot convert right now, we may have to support 
port version 1 and 2, and I cannot answer this question.

First question, do we want support a version 1 and version 2 of this 
port?

Given that 1.3.1 fixes some bugs in 1.2 but IMO has a more restrictive 
license do we have one or two version 1 ports?

Tripwire version 2 is a complete rewrite of the product.  The memory 
management issues of version 1 no longer exist.  Version 2.3.1 is GPL 
making its license more restrictive than 1.2 but less restrictive than 
1.3.1.

If given a choice, and I had to choose one, I'd replace both version 1 
ports with 2.3.1.  If I could keep one version 1 port and the version 2 
port I would keep the 1.3.1 port, with its more restrictive license, 
and the 2.3.1 ports in the tree.

Finally, thinking about it a little more (the more I think of this the 
more I'm convinced that the committer was right and I was wrong), 
maintaining an old port forever doesn't make much sense.  I'd publish 
on -security, -ports, and -announce that as of date XXX both Tripwire 
version 1 ports will cease to exist.  I suppose we could mark the old 
ports broken or restricted for 6 months with the explanation that they 
will be going away on, for example, March 1, 2002.  This way we can 
satisfy the requirement that users of the old ports will have time to 
convert.

So I'm back to my original question.  Given the licensing and 
functional reasons, what do we want to do?  If nobody cares, I'd be 
happy to replace both version 1 ports with a version 2 port.  If anyone 
does care I'd be happy to continue maintaining 1.3.1 and 2.3.1 (I don't 
maintain the 1.2 port), please speak up or forever hold your peace.  
I'd be happy either way as long as we have a version 2 port (which 
explains the ambiguity of my first two notes).  I don't have a strong 
opinion about keeping the old ports, though I do have a strong opinion 
about having the version 2 port in the tree.  In regards to the version 
1 ports I only want to do what the list wants to do.


Regards,                         Phone:  (250)387-8437
Cy Schubert                        Fax:  (250)387-5766
Team Leader, Sun/Alpha Team   Internet:  Cy.Schubert at osg.gov.bc.ca
Open Systems Group, ITSD
Ministry of Management Services
Province of BC



To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message