[ports] finding an orphan to maintain

[Roland Smith]

On Thu, Jan 12, 2017 at 09:21:16PM +0100, Damien Fleuriot wrote:
> On 12 January 2017 at 17:47, Roland Smith <rsmith at xs4all.nl> wrote:
> > On Wed, Jan 11, 2017 at 12:53:02PM +0100, Damien Fleuriot wrote:
> >> Thanks for the additional input Roland.
> >>
> >> I currently have my eye on shells/lshell, which we use here on
> >> 10-STABLE for PCI-DSS compliance (restricting and logging commands).
> >
> > In this case you might want to look at auditing;
> > https://www.freebsd.org/doc/handbook/audit.html
> >
> > While the handbook explains how it works, I haven't really found good examples
> > of its use.
> >
> 
> I thank you for the input and have indeed already looked at auditd.
> 
> While it does provide very good logging, it only answers one of the
> prerequisites, logging, not actual command restriction.

There is another (somewhat heavyhanded) approach to restricting commands.
You could copy binaries for allowed programs to a special directory (to be put
in $PATH) and remove read/execute access for others from the normal `bin` directories.

> We do have another constraint which is that the software be portable
> to linux as well, so as to not maintain 2 different sets of
> logging/restriction stacks.

I thought OpenBSM was ported to Linux, but it seems to miss auditd because of
kernel support. Pity.

> >> It so happens the current (0.9.16_2) version on FreeBSD suffers from a
> >> nasty case of shell escape :
> >> https://github.com/ghantoos/lshell/issues/151
> >> root:~$ echo () sh && echo
> >> #
> >> ^-- uh oh...
> >
> > Oops.
> >
> > Looking at the discussion of the issue, I get the impression that there are
> > some fundamental problems with the way lshell parses and executes commands.
> >
> 
> Aye, bug reporter seems quite adamant that, quote, the software is
> entirely broken.

Not a good sign. And I think he has a point, seeing how lshell uses Python's
subprocess module.

> >> I cannot seem to reproduce when using the latest master branch, and am
> >> seeking confirmation in the bug thread that I'm actually trying to
> >> reproduce correctly.
> >>
> >> If it should transpire that the problem is indeed fixed in the master,
> >> I shall try and update the port to the latest version.
> >
> > The port now uses SourceForge, which is getting a bad reputation these days
> > for adding crap to binary installers. This is probably not an issue with
> > tarballs, but it makes me wonder if they are still trustworthy.  You might
> > want to consider switching to github. If you do, read
> > /usr/ports/Mk/bsd.sites.mk on how to properly do that in the port Makefile.
> >
> 
> When (if) I manage to get Poudriere up and running (it's currently
> bitching about missing /usr/local/share/poudriere/jail.sh), I shall be
> able to submit run tests for a patched version of shells/lshell.

For just one port, bringing up Poudiere is surely overkill?

My workflow for modifying a port is generally as follows (using sysutils/conky
as an example):

    > mkdir scratch
    > cd scratch/
    > cp -Rp /usr/ports/sysutils/conky .
    > cp -Rp /usr/ports/sysutils/conky conky.orig
    > cd conky/
    [Make whatever changes necessary, then run the following tests (from the
    Porters Handbook) *as a normal user*, unless otherwise (#) indicated]
    > make stage
    > make check-orphans
    > make package
    > portlint .
    # make install
    # make deinstall
    # pkg add package-filename
    # pkg delete package-filename

When all this works,

    # make clean
    > cd ..
    > diff -ruN conky.orig/ conky/ > patch-for-conky.diff

Attach the diff to a PR.

> The aim is to bring it up to upstream from github at version 0.9.18.
>
> Sadly lot of vulns were patched since 0.9.18 and there is no further
> release tag.
>
> I've asked for one today, wait and see.

The documentation for github in bsd.sites.mk states that you can use a hash
from a commit as a GH_TAGNAME.

Roland
-- 
R.F.Smith                                   http://rsmith.home.xs4all.nl/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
THUBpgp: 5753 3324 1661 B0FE 8D93  FCED 40F6 D5DC A38A 33E0 (keyID: A38A33E0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20170114/9549865a/attachment.sig>