On 20/4/17 6:29 am, Dewayne Geraghty wrote:
Scratch65535, I think your best solution is to use latest and upgrade when
you need to. Unlike Freddie's comment re only desktop users using latest.
I ONLY upgrade my local svn of ports when there's a vulnerability or
significant (for users) functional improvement of a port.
It is a labour intensive exercise, monitoring CVE's for all
externally-facing applications.
Its a nice idea having a snapshot of ports, from the perspective of
consistency, but that model doesnt suite our risk appetite on multiple
levels; and in our view back-porting fixes to a quarterly snapshot - a good
idea from a security perspective it is a really bad idea from a
consistency/administrative/audit perspective.
We mirror the ports tree (and base) into p4 and also as svn, and use
this to check out the head branch to whatever release we need.
Our scripts are capable of checking out a particular port at a
(slightly) different rev to the default rev used for the rest, as
sometimes we find we need a slightly newer rev of one port or
another. This sometimes doesn't work if there are framework changes
that affect the port but mostly we find that it's ok if you just want
to bump a port up a small amount to catch a bugfix,or take it back a
bit to avoid a regression. We also do sparse checkouts of the ports
tree ot save time, but that's another issue..
We therefore have all out pkgs (which we store with each release) at
the same level of source tree so they all match.
How the ports infrastructure can meet many conflicting objectives is
something that we (the consumers of the ports service) must decide for our
circumstance. The use-the-latest paradigm suits individuals that manage
their individual machine, but when you manage multiple clients' servers,
the requirements are different (try meeting a SAS70-II/SAE16-SOC2, ISO27001
SOA, NIST 800-53r5, etc)
On a non-audit level, Microsoft might hold to monthly updates/fixes ("patch
Tuesday") but bad guys don't.
Regards, Dewayne.
_______________________________________________
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"
