In D24990#550370, @salvadore wrote:

On second thought, I must ensure that xiphos still compiles with the updated biblesync. So I need to test it before I commit this update.

Thus I propose to also remove USE_GCC from xiphos now instead of when I will update it.

In D24990#550247, @salvadore wrote:

I did not even knew that we could add comments to patches: thanks mentor :)
I added a comment: can you please check the file again to confirm that I did it properly, since it is the first time? Thanks!

Looks fine to me.

This is great progress. i386-wine never even went to Wine 4.x, so this is a big jump from 3.x to the new 5.0.

In D24644#542490, @salvadore wrote:

Committed taking into account your comments.

Looks okay to me, and the longer commit message definitely is a good idea.

In D24573#540690, @tcberner wrote:

I would either include it by default (it's a file, it won't be 10G big...) or reuse the NLS option.

I don't get why this is an option. Why not simply install it?

In D24374#536165, @salvadore wrote:

On the contrary, when it will eventually become libssh.so.5 I will have to bump PORTREVISIONs, am I right?

Oh, I thought you had committed this already. Please make sure you ack antoine@ for the exp-run.

In D24377#538854, @salvadore wrote:

I kept searching upstream and found the git commit that fixed the vulnerability:
https://git.libssh.org/projects/libssh.git/commit/?id=b36272eac1b36982598c10de7af0a501582de07a

I asked the committer if he could tell me the discovery date, as I cannot access the bug report referenced in the commit log: he has not answered yet.
If he does not answer, shall I put 2020-02-11 as discovery date? This is the date in the author field of the git commit (not sure what it represents however).
According to https://bugzilla.redhat.com/show_bug.cgi?id=1801998 the vulnerability was known in 2020-02-12.

In D24385#536374, @salvadore wrote:

@gerald, @tcberner (mentors): To speed up my work on doc tree, could I assume that I get mentor approval from you on a doc tree commit each time I get a doc committer approval?

Regarding your interpretation, indeed it appears the Porters' Handbook needs fixing. Can you please file a PR or Phabricator item and use that to check in with secteam@FreeBSD.org ?

In D24377#536225, @salvadore wrote:

1 - I do not know the real discovery date: I put the date when I learned about the CVE and when the update to version 0.9.4 that fixes the vulnerabilty has been released, but it is unlikely that it is the real discovery date. I tried not putting such a date (no discovery field or "before 2020-04-10"), but nothing, make validate enforces a date in %Y-%m-%d format.

Isn't this your specific domain, Lorenzo (regardless of whether you are a doc committer or no)?

As you commmit, can you please explain (a bit) what happened around the incorrect distinfos
in the commit log?

Looks good, thank you.

Obviously okay with me (as your mentor) once a doc committer approves.

In the commit message please refer to the "upstream" (as in wine-devel) commit.

What do you mean by refering to upstream in that case?

Sure. Didn't I pre-approve this backport from wine-devel?

Yep, thank you.

My point was in reference to git id 9e57333 (before) versus git id (9e573336) after, though in hindsight I realized that may be in reference to the same id, just one additional significant digit.

In D24167#531990, @salvadore wrote:

Committed. If this commit works as expected, we will need to forward it to emulators/wine, as emulators/i386-wine is affected by the same bug.

So this previously missed the last digit of the git commit id in question? How comes this did not show up in testing?

Looks fine (assuming you have tested as usual).

I am adding my approval as Lorenzo's mentor (on the ports side), which is formally required - leaving the actual review into the hands of the (Italian speaking) doc committers here.

Here is what I wrote yesterday, but failed to hit "Submit":

In D24104#531131, @salvadore wrote:

By the way, I just realized that up to now we have indeed distributed through binary packages the modified rc script, without any declaration on copyrights and license for these modifications. And we regularly do that in the ports tree for any port that patches the files it fetches. I guess then that it would be fine to just continue doing that?

There's two aspects I'd love some people with more expertise to chime in: