Bump dep boring ssl (non-fips)

[GlenDC]

There are some useful updates that happened in the last couple of years, but seems that you still link to a pretty “old” commit of googles deps.

I understand why this is for FIPS, but how come this is also for the non-fips? Is this possible to update? And if so, do you need help with this?

[rushilmehra]

Hey Glen - there's not really a good reason for the submoduled boringssl to be this old. That said, you're able to provide your own precompiled boringssl or even a filepath to the repository and our build scripts will respect that. This is what a lot of internal projects do, so that's the approach I would recommend in the immediate term.

I would love to get rid of the submoduled approach entirely - in an ideal world users provide their own boringssl at all times. That does make the crate a bit more difficult to use though, so maybe instead we get into the habit of regularly bumping the submoduled commits.

[GlenDC]

Oh ok, that would just work? Would have thought it might also require work in the bindings? But your answer seems to imply that the API is rather stable than, even over a span of multiple years

[rushilmehra]

We use varying versions of boringssl with these bindings internally. Honestly I can't guarantee that the most recent version of boringssl will work bug-free with the existing bindings. Last time I tried to build the crate with latest HEAD, things did compile, but I didn't sanity check anything beyond that

[GlenDC]

Hmm seems less trivial as advertised. You seem to have custom patches. Which aren't that useful for recent boringssl versions as the code structure and file structure alike has changed. I suppose that means you do not use any feature flags for the cases where you use other boringssl versions?

[rushilmehra]

Generally speaking, whenever we pass a custom boringssl to the bindings, we set BORING_BSSL_ASSUME_PATCHED to skip applying patches at build time. The patches in-repo are pretty specific to the current submoduled versions of boringssl, so they break with newer versions

[GlenDC]

Generally speaking, whenever we pass a custom boringssl to the bindings, we set BORING_BSSL_ASSUME_PATCHED to skip applying patches at build time. The patches in-repo are pretty specific to the current submoduled versions of boringssl, so they break with newer versions

Yes I assumed as much. But unless I miss something that means that:

• you either do not enable these feature flags (rpk, pq-experimental, underscore-wildcards)
• or have similar patches in these custom boringssl paths

No? Because it seems that your bindings (with the relevant feature flags enabled) rely on this custom code.

[rushilmehra]

Yeah whenever we use those features it's expected the custom version of boringssl will have the patch baked in. Otherwise the crate would fail to compile. Is there a specific feature you're trying to use with a newer boringssl?

[GlenDC]

Is there a specific feature you're trying to use with a newer boringssl?

No, not really. It's more of an attitude in trying to keep dependencies up to date. As intuitively I would think that 2+ years of a gap probably means there are plenty of improvements that one could benefit from. But no real blocker and neither demanding anything here.

I mostly was wondering and from what our conversation has been so far I gather that there is no technical reason on your end why there is that reference to an old commit other than the fact that it didn't ever get tasked.

Last night I gave a first stab in trying to port those patches to the latest release of google's boringssl.

• the patches itself can no longer be applied as there is just too big of a gap in file and code structure
• that in itself is not too big of a deal as it's fairly trivial to map these changes manually to the new layout (*)
• there are however a couple of things that have changed to the point that I would need a deeper look in what is the intent and how the dependency code is now. E.g. in one of your patches you have functions that set the private key directly but that property no longer exists in the new CERT class dep code. Just to give an example

(*) However even though most changes seem fairly trivial to port, I am still doing it mostly blindly for now as I have not yet a good enough understanding of what those patches try to achieve and how the boringssl codebase has evolved since.

As such for now I am back on the commits that you have checked in this repository and have delayed that work for a bit.

With that all said however, in case you are open for contributions I don't mind opening a PR where I try to update those patches and get you to a more up to date boringssl commit:

• that would probably better as I would be able to ask questions and get some validation on these changes
• it would require you or a colleague to tell me what commits would be best for me to point at. Would be the latest release? some release before that?

In worst case I'll just give it another stab on my own in some weeks after I've gotten a clearer understanding of it all, and apply it directly into my own mirror. But if all the same for you I would prefer to do it in collaboration with you all. These patch files are also pretty painful to maintain I think if you do not stay up to date. I wonder if there is no easier way. Usually I would just keep my own fork and apply directly on that, but I suppose that wouldn't allow you to reuse the same patches on different versions of these deps. Still, flawless it isn't either.