While I still don't quite know how we got from 8.0 to 8.2.
It all LGTM. Thanks for all your time and efforts here, Otis.

In D37706#857873, @otis wrote:

In D37706#857617, @portmaster_BSDforge.com wrote:

I started this yesterday, But was involved in a head-on collision Monday. So I'm not yet recovered. :(
I ran into the following error using the HTTP(s) mirrored source, building in a 12 jail:

checking for ASIdentifiers_free... no
configure: error: libcrypto with RFC3779 support required
===>  Script "configure" failed unexpectedly.
I think the SSL may be behind in that jail.

Has anyone tried these proposed changes?

It builds with 12.4-RELEASE jail.

I chose the following. As it seemed less prone to failures:

I started this yesterday, But was involved in a head-on collision Monday. So I'm not yet recovered. :(
I ran into the following error using the HTTP(s) mirrored source, building in a 12 jail:

My only objection is that I can NOT get textmode or very stable X on any of the NVIDIA
cards I use unless I build against sc. Does sc(4) use so much space that current kernels
become too big with it's presence? I vote against it's removal.

In D30807#695747, @grembo wrote:

In D30807#695734, @ceri wrote:

'approved', 'allowed', 'rejected': may be clearer.

Those aren't really terms that are usually used in the context of certificates though and using them might raise more questions. It really just seems to be "all certificates" and out of those "trusted ones" (like the "manage certificates" dialog in firefox - you can import and then modify the trust level).

I like your concept. or maybe,
removed, retired, rejected?
lastly, IMHO DIStrusted /would/ be the better than UNtrusted, if us/english is not your first spoken language / "native tongue".

Thanks for all the work you put into this, Stefan!
Having done it the way it's always been done all these years.
This all seemed initially unintuitive. But it's elegant in it's
simplicity, and simplicity is something I can easily get used to. ;-)
Everything looks right to me. So if I have anything to say about
this; consider this an approval. I'm looking forward to it's adoption.

In D30160#677202, @hselasky wrote:

@swills : Yes, but how to avoid problem with other OS'es implementation? Do you have any suggestion for which command line arguments are free?

In D26447#664044, @pstef wrote:

In D26447#664004, @rgrimes wrote:

Also so much for the project being a democracy, seems that core@ and security@ now simply dictate to developers@ how things are to be done...

Democracy as you describe it effectively means nothing ever changes because there is always someone whose feelings are hurt by a decision made.

Ahem. As you already noted; Democracy is a majority. *Which* majority is something else.
I'd only like to add that democracy is akin to popularity. User popularity keeps FreeBSD alive. Isn't that pole FreeBSD took, what drove the decision to adopt git as the source of future truth for FreeBSD? If ftp(d) is a popular component of base, as the vast majority of mailing list replies would seem to indicate. Maybe it's worth keeping?

In D26447#663880, @gordon wrote:

To be clear, this isn't a referendum on whether we should deprecate ftpd. We are going to deprecate it. There is no need for ftpd to live in the base system. It hasn't been a core system daemon in at least 10 years, probably closer to 15 years.

Referendum or not. The mailing lists reaction should be evidence enough that the FreeBSD user base (those for which FreeBSD exists) have a different opinion on this decision.

In D26447#588691, @cy wrote:

I think we should deprecate the client as well. F5 no longer supports the FTP protocol.

Another thought: Deprecate and remove telnet. It's already in contrib and could be very easily moved to ports. (I'll put that on my todo list.)

MacOS has also done this.
I don't understand why this should be necessary. In fact *because* MacOS depreciated client && server. I discovered it was trivial to simply copy my already built FreeBSD version over to MacOS and use it there. I found it much nicer than the GNU version. :-) Why remove them? I have used and depend on both for _years_. inetd(8) && hosts.allow(5) provide reasonable enough security. Or are they being removed as well?

This was created in error

OK I'm a reasonably intelligent individual. But the software used
for this appears to me to be fairly clueless. In my attempt to
update this differential with a newer diff. It created:
https://reviews.freebsd.org/D27593
Sorry. I simply followed the direction this software took me.

OK I have a proper diff that makes all the necessary corrections. I went to attach it
to this differential, and submit took me to a different differential. I'm unclear how
anyone gets along here.
I'll try to attach it again.

I'm updating the original proposed diff with the changes
necessary to accomplish the original goal.
UPDATES MOVED
UPDATES PORTVERSION
REMOVES PORTREVISION
REMOVES pkg-plist
ADDS autoplist
bumps version in port source (taylor.py)
UPDATES distinfo

Wait a minute. I should really fix the version in the source itself (vcpx_tailor.py).
Can you pull that patch from this differential, and I'll submit the correct diff to the pr.
Or is there a better way, like make all these proposed changes to the pr this differential references?
Sorry. I have limited experience with these differentials, and the preferred procedure.

LGTM
I'm embarrassed I forgot MOVED, as well as *version* in vcpx_tailor.py.

I'm with @koobs on an "informative" error returned on this. If it's possible.
I think it might lend itself to *Maintainers* providing a cure. :)
Thanks for all the time, and effort put into this!

In D15480#327568, @tcberner wrote:

@mat does not seem to mind it, so it's OK, I gueess =)

But could you give them more sensible names like tkdiff-256.png.enc or something instead of just 256.

This version simply changes the names of the icon files, as per @tcberner 's request.

Thanks Mat!
I made the changes you suggested/required, and attempted to add it to this review, by choosing Update Diff from the menu.
But I don't think that was the correct way to do it, as I don't see the change(s).
Sorry, I'm afraid phabricator is still a bit unfamiliar to me.
FWIW I also added the new diff to pr bug #228176

In D15480#327198, @tcberner wrote:

My issue is more with them being shipped in files/ and not downloaded from somewhere -- you could for example create a tkdiff-icons.tar.gz and host it in your public distfiles and add it as an additional distfile.

In D15480#326764, @tcberner wrote:

I'm not sure about the icon handling there... seems a bit icky.

The general solution is to make it easy in the installer to select from a few presets for all of these that will give the desired behaviour. At a previous DevSummit, there was talk of having a Linux-user-friendly port that would provide a bunch of these as a simple installable option. That seems a far better place to focus effort than a bikeshed discussion about whether we like less or more for one specific use.

FWIW I too am big on sticking to POLA. But (personally) in this case I'd be up for the change
(enhancement) providing there was an item added in UPDATING, with the directions to reverse
it, and make that reversal stick.

In D6820#143262, @woodsb02 wrote:

Thanks for the review mat. Waiting on maintainer feedback from Chris Hutchinson before committing.

In version 1.0.0 source was restricted to owner rwx which means
only root can install. I had to prepend the following here