Will wait here for the non-FreeBSD maintainer timeout as well.

In D48698#1111322, @jrm wrote:

In D48698#1111309, @michaelo wrote:

Will leave time until Saturday and then will merge.

Maintainer timeout is two weeks. https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-maintainer

Guys, do you want to review?

Will leave time until Saturday and then will merge.

Will leave time until Saturday and then will merge.

Built all depending packages in poudriere. All passed. Waiting for sunpoet.

In D48698#1110905, @jrm wrote:

Looks good. Ideally, we would confirm that the reverse dependencies [0] are good.

[0] My quick grep of the tree shows:

databases/py-psycopg:

databases/py-Pyrseas
databases/py-pgcli
databases/py-pgspecial
databases/py-sqlalchemy20
net-mgmt/netbox
devel/py-frictionless

databaes/py-psycopg-c:

databases/py-psycopg
net-mgmt/netbox

Even without the patch it does not compile: https://github.com/protobuf-c/protobuf-c/issues/730

THIS IS A DRAFT, READ INCOMPLETE. I have tried to reduced the patch based on the changes from https://github.com/protobuf-c/protobuf-c/compare/v1.4.1...v1.5.0. The patch does not apply cleanly, maybe it can be completely removed, but @truckman should tell us.

In D48669#1110019, @jrm wrote:

Looks good, but we should also hear from @sunpoet. (That's always implied when I approve changes to a port someone else maintains.)

In D48653#1109570, @jrm wrote:

In the commit log, you say,

List also the Python version limitation since none is documented.

Do you mean remove the python version limitation?

Update commit message

Upstream:

• https://pypi.org/project/psycopg/
• https://pypi.org/project/psycopg2/

In D48223#1105308, @haraldei_anduin.net wrote:

@jrm Yeah, I was mostly thinking about the quality of production code backtraces :) A full strip will clearly strip more than just debug info. It will probably make a difference for internal errors in the JVM itself, but not much for code running _on_ the JVM.

Update commit message

In D48223#1105116, @haraldei_anduin.net wrote:

In D48223#1105110, @michaelo wrote:

It depends, sometimes you simply cannot reproduce on non-prod. Does this affect jstack? This is often requested on the Tomcat mailing lists.

I think so, but only native code. The stack traces should still include all the information that the JVM itself handles.

In D48223#1101554, @haraldei_anduin.net wrote:

I think this should be ok. There are some parts of the handling of internal errors that tries to look up debug info to get better stacktraces, but I don't think that is important to production deployments.

In D48313#1102926, @jrm wrote:

In D48313#1102823, @otis wrote:

What is the rationale behind this change, please? Moreover, I guess @jrm is the best samba person in this ballroom.

FWIW, if I've ever run Samba, it was over 20 years ago.

It would be nice to hear from someone on samba@. Are there any open questions from bug#277878? If not, and @michaelo, if you are satisfied this is safe, I will approve.

In D48313#1102933, @michaelo wrote:

In D48313#1102927, @jrm wrote:

Another question, is this applicable to net/samba416?

Samba 4.16 is completely different, due to new VFS code they do not really compare, but I can check.

In D48313#1102927, @jrm wrote:

Another question, is this applicable to net/samba416?

In D48313#1102926, @jrm wrote:

In D48313#1102823, @otis wrote:

What is the rationale behind this change, please? Moreover, I guess @jrm is the best samba person in this ballroom.

FWIW, if I've ever run Samba, it was over 20 years ago.

It would be nice to hear from someone on samba@. Are there any open questions from bug#277878? If not, and @michaelo, if you are satisfied this is safe, I will approve.

In D48313#1102823, @otis wrote:

What is the rationale behind this change, please? Moreover, I guess @jrm is the best samba person in this ballroom.

Any opinions?

Bump port revision

In D48171#1098620, @fuz wrote:

Why don't you change these to your FreeBSD.org address? That one is guaranteed to remain as-is.

In D48171#1098375, @jrm wrote:

You also have two entries in UPDATING with that address (in case you also want to change those).

For the stupid: I have once grepped through Java's C code and wasn't able to find any use of those filesystems, I really wonder why they are needed at all here.

In D48169#1098351, @jrm wrote:

How about making the subject line of your commit message devel/subversion{,-lts}: Update to 1.14.5? This way, the prefix is specific and the first letter of the subject is a capital.

In D47865#1096992, @jrm wrote:

Your change seems simple enough. If you're confident, go for it. If you want review from a src committer, you'll have to pester someone.

Is @fluffy's review enough to merge this? Does @fluffy have src commit bit?

Anyone willing to review?

FTR: The maintainer didn't responsd within four months.

Jailhost before patch:

root@deblndw013x:/compat/linux/proc/self
# cat mounts
cat: mounts: Operation canceled

Please add others you think see fit.

Will look again next couple of days.

FTR: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcarevocationcheck with chain, leaf, none.

In D47433#1082495, @franco_opnsense.org wrote:

In D47433#1082491, @michaelo wrote:

I don't disagree, but introducing multiple vars for the same config isn't better either in my opinion. Consider you want to expose that to the CLI for fetch(1), do you want to introduce multiple switches?

For historic context: right now handling of X509_V_ERR_UNABLE_TO_GET_CRL / D47449 is unconditional for OPNsense due to lack of the scope of this patch here. For FreeBSD inclusion I pondered the side effect of introducing this breaking standard verification behaviour of SSL_CRL_FILE and there it would also be beneficial.

In D47433#1082489, @franco_opnsense.org wrote:

In D47433#1082488, @michaelo wrote:

Well, then maybe SSL_VERIFY_CRL should not be boolean, but rather an enum? E.g, optional, yes, much like https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslverifyclient because it the end it will require more and more flags. Default value would be none/NULL.

Also doable, but personally I dislike the fuzzy matching on the value to act according to user (case sensitivity and ambiguity of yes and no etc and garbage input). The vars in libfetch are set and forget, if referencing a file or dir letting other parts deal with the complexity of the validation too.

In D47433#1082487, @franco_opnsense.org wrote:

In D47433#1082486, @michaelo wrote:

Like fine, but then CR, not CRL because we don't verify the list, do we? :-D Since it is a *verbose* flag I don't mind being verbose literally.

Technically the list's signature and expiry is verified as well but we could also call it a "check" but then the env var should be renamed for clarity as well? Already expected the naming aspect of it to be difficult but I agree that it should be as good as it can be since it will likely stay that way.

In D47433#1082485, @franco_opnsense.org wrote:

Oh about SSL_VERIFY or SSL_CRL I'm not sure. Keeping it closer to SSL_CRL_FILE may be more beneficial also with SSL_CRL_OPTIONAL in mind later. Don't want these vars too long if it can be avoided and cluster all CRL into SSL_CRL prefix?

In D47433#1082484, @franco_opnsense.org wrote:

In D47433#1082483, @michaelo wrote:

WDYT?

I'm ok with that, maybe with brevity in mind just this:

CRL verification enabled

But I don't mind either way.

I see inconsistency in env vars and in output:

I have now played around with the patch and one of our intermediate CAs:

While testing this, do you intend to add a flag to fetch(1) as well? E.g., --crl-verify?

I think I have found it, the documentation isn't really good in this case for both SSL_CTX_load_verify_locations() and SSL_CTX_set_default_verify_paths(). If a hashed dir is passed it boils down to https://github.com/openssl/openssl/blob/ccaa754b5f66cc50d8ecbac48b38268e2acd715e/crypto/x509/x509_d2.c#L73-L76 where the manpage says:

X509_LOOKUP_add_dir() passes a directory specification from which certificates and CRLs are loaded on demand into the associated X509_STORE. type indicates what type of object is expected. This can only be used with a lookup using the implementation X509_LOOKUP_hash_dir(3).