Review request

[depa...@redhat.com]

Hello,

Could I please have somebody take a look at https://go-review.googlesource.com/c/go/+/333049.

It's an initial refactor CL for the boringcrypto branch which aims to add support for using OpenSSL as well (in future CLs).

[depa...@redhat.com]

Hello, just wanted to ping this thread again as there hasn't been any activity on the CL.

[depa...@redhat.com]

Hello,

Is this mailing list still being monitored? Is there some other avenue I should take to reach out to folks? I hate to bug and be a pest, but it would really be great to get some feedback on the patch mentioned in this thread. I'd appreciate even a simple 'Ack' to know that someone has seen this.

[Josh Bleecher Snyder]

Hi!

People do read this mailing list, and your message did make it through.

I'm not sure who is responsible for the boringcrypto branch. I apologize for the delays in review. You're not being a pest; you're following up, and that's very reasonable.

-josh

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/842f7e8d-4499-4d76-b83b-afc6a32888b4n%40googlegroups.com.

[Jeremy Faller]

As Josh stated, we do monitor the list. Apologies for the poor communication. Sometimes we all think someone else is sending an update, and no one ends up doing it...

We had a small snafu with boringcrypto, as we're transferring responsibilities for it's maintenance around internally. This branch will be updated with the next point release for Golang. Following our published process, unless a security release causes rescheduling, that next point release will happen this week, and boringcrypto will be updated soon after now that we've sorted out responsibilities.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAFAcib-mcgK1HmyZgawCFD1%3DAf5gVynZutDyNCW-Wv6ge6wB3Q%40mail.gmail.com.

--

Warmest Regards,
Jeremy Faller

[Jeremy Faller]

And to answer your question (context was lost as it bounced around):

I don't think OpenSSL support is on our roadmap for boringcrypto. I would recommend a fork, and your continued development there.

[depa...@redhat.com]

Thank you for the response, I really appreciate it! I also definitely how things can fall through the cracks a bit with restructuring so no worries there!

As far as the rebase goes, that's great news! We have some work downstream that depends on the dev.boringcrypto branch and we've been blocked waiting for a non-rc rebase upstream.

For OpenSSL, I had spoken with Filippo personally a while back (there was delay afterwards on my end as I started paternity leave) about upstreaming some work we've done at Red Hat in order to make the dev.boringcrypto branch be able to alternatively use OpenSSL (essentially boringcrypto would continue to work, but openssl would also be an option) and was under the impression that CLs implementing this feature would be happily received and considered with the caveat that I also sign on for continued maintenance and helping get any kind of necessary CI set up.

At Red Hat we're not too keen on maintaining our own forks, we like to try and upstream everything as much as we possibly can to get the most eyes and community involvement in anything we do, and to contribute back to the ecosystem as a whole.

[Jeremy Faller]

On Mon, Oct 4, 2021 at 3:10 PM depa...@redhat.com <depa...@redhat.com> wrote:

Thank you for the response, I really appreciate it! I also definitely how things can fall through the cracks a bit with restructuring so no worries there!

As far as the rebase goes, that's great news! We have some work downstream that depends on the dev.boringcrypto branch and we've been blocked waiting for a non-rc rebase upstream.

For OpenSSL, I had spoken with Filippo personally a while back (there was delay afterwards on my end as I started paternity leave) about upstreaming some work we've done at Red Hat in order to make the dev.boringcrypto branch be able to alternatively use OpenSSL (essentially boringcrypto would continue to work, but openssl would also be an option) and was under the impression that CLs implementing this feature would be happily received and considered with the caveat that I also sign on for continued maintenance and helping get any kind of necessary CI set up.

At Red Hat we're not too keen on maintaining our own forks, we like to try and upstream everything as much as we possibly can to get the most eyes and community involvement in anything we do, and to contribute back to the ecosystem as a whole.

I've always loved and respected Redhat's commitment to the OS community. Thank you for pushing us on this and trying to make Go better.

I can't comment on conversations that you and Fillipo had privately. I can say that our broader security efforts have been stretched thin. You can see it as a side-effect of the inability to get a reviewer, and by proxy our inability to get boringcrypto out the door with the point releases on time. While we're working on fixing the holes, I don't think we can find the bandwidth to offer the support this work needs. As boringcrypto is a published best-effort task, adding features falls outside our scope while we try to focus on core work. This is not to say it won't change in the future, but we're trying to hold back the tide right now without adding more work.

I'm happy to discuss this in (virtual) person if you'd like.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/1f80c5b8-3eba-4896-8f87-6a7346c3bb6fn%40googlegroups.com.

[depa...@redhat.com]

I would actually really appreciate that! Would you mind reaching out to me off-list so we can discuss a time to meet?

[Jared Parsons]

Microsoft is interested in this change as we have scenarios where we need to defer to OpenSSL for our crypto implementations.  

> At Red Hat we're not too keen on maintaining our own forks, we like to try and upstream everything as much as we possibly can to get the most eyes and community involvement in anything we do, and to contribute back to the ecosystem as a whole.

Feel strongly the same way. If the end conclusion is that a fork must be created then we'd like to help with that fork to ease the burden (and share the work). But ideally we'd like to not have to do this.

[Michael Hudson-Doyle]

On Thu, 7 Oct 2021 at 13:04, 'Jared Parsons' via golang-dev <golan...@googlegroups.com> wrote:

Microsoft is interested in this change as we have scenarios where we need to defer to OpenSSL for our crypto implementations.  

> At Red Hat we're not too keen on maintaining our own forks, we like to try and upstream everything as much as we possibly can to get the most eyes and community involvement in anything we do, and to contribute back to the ecosystem as a whole.

Feel strongly the same way. If the end conclusion is that a fork must be created then we'd like to help with that fork to ease the burden (and share the work). But ideally we'd like to not have to do this.

It turns out Canonical has exactly the same desires and concerns as well. Does it make sense to collaborate on this work somehow / somewhere? If it's going to continue to be based on dev.boringcrypto and the plan is for that to remain unmerged, I don't know how far upstream this can be pushed.

Cheers,

mwh