Missing 1.78 release tag?

[hw207165]

Could add a tag for 1.78 version

[dghgit]

I'm still waiting on 1 item of documentation.

[ertong0129]

I need a tag, too

[Hatawenzi]

I need a tag,three

[dghgit]

Still waiting...

[rlyan2022]

Waiting...

[woo202403]

Still no 1.78 release tag.... QAQ ... @dghgit

[dghgit]

Still no CVE ID.

[hw207165]

Still no CVE ID.

This one?

https://www.bouncycastle.org/releasenotes.html

CVE-2024-301XX - When endpoint identification is enabled and an SSL socket is not created with an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address. This has been fixed.

[dghgit]

Yep, that's the one.

[woo202403]

Still no CVE ID.

https://www.bouncycastle.org/releasenotes.html

Why does the list of resolved bugs have an indeterminate CVE ID? In addition, the code build package of version 1.78 has been determined in the Maven repository, which means that the code is ready. @dghgit

Why do you need to wait for the CVE ID when adding a tag? 😥

[dghgit]

So the CVE ID was requested a bit over a week ago, prior to the roleout. Usually we hear back within 24 hours, however this time around it's taking longer. No idea why, but that's why there is an indeterminate CVE, and as the documentation is part of the code I can't do a final tag till I've actually been able to complete the documentation. Frustrating I know.

As an aside, there's issues with the OSGI manifests in this release, the bcutil jar changed it's exports, and somehow the org.bouncycastle import clause was deleted from some of the ancillary jars. At any rate it means I'll be following up with a 1.78.1 in the next few days.

[woo202403]

So the CVE ID was requested a bit over a week ago, prior to the roleout. Usually we hear back within 24 hours, however this time around it's taking longer. No idea why, but that's why there is an indeterminate CVE, and as the documentation is part of the code I can't do a final tag till I've actually been able to complete the documentation. Frustrating I know.

As an aside, there's issues with the OSGI manifests in this release, the bcutil jar changed it's exports, and somehow the org.bouncycastle import clause was deleted from some of the ancillary jars. At any rate it means I'll be following up with a 1.78.1 in the next few days.

Understand now. Thank you for your work. 👍 @dghgit
Waiting1.78.1

[hw207165]

So the CVE ID was requested a bit over a week ago, prior to the roleout. Usually we hear back within 24 hours, however this time around it's taking longer. No idea why, but that's why there is an indeterminate CVE, and as the documentation is part of the code I can't do a final tag till I've actually been able to complete the documentation. Frustrating I know.

As an aside, there's issues with the OSGI manifests in this release, the bcutil jar changed it's exports, and somehow the org.bouncycastle import clause was deleted from some of the ancillary jars. At any rate it means I'll be following up with a 1.78.1 in the next few days.

What's the plan of 1.78.1 ?

[smile12456]

I need a tag, too

[smile12456]

missing1.78.1 tag

[dghgit]

Okay, I'll admit this has now gotten a bit crazy. I'm in the process of publishing the 1.78.1 artifacts now. When that's done I'll do the tags regardless of whether we have the CVE ID or not. It's not ideal, but it looks like we'll have to update the documentation after the fact. I'll still move the tag in our version of the repo, but it's going to be very difficult for people who've branched off the tag earlier to keep track of this. Apologies, I really thought we'd have the ID by now, it's quite unprecedented that it's taken so long.

[dghgit]

Tags should be showing up shortly. Recommend building off r1rv78v1 rather than r1rv78.

Still no sign of CVE ID.

[dghgit]

Tag now published, to re-iterate recommend using r1rv78v1

[Marcono1234]

@dghgit, it is possible to create a GitHub advisory and then request a CVE for it. Maybe that could be an alternative for you in the future?
That might make it easier for you to specify the details, and to obtain a CVE.

[dghgit]

The advantage of requesting one directly is we can maintain control of publication - for serious CVEs there is often an embargo period, so the ID gets allocated well before publishing. I was at the CERT advisory meeting a couple of weeks ago before RSA, it seems the issues that caused the delay at MITRE on this occasion have been dealt with,

[Marcono1234]

we can maintain control of publication - for serious CVEs there is often an embargo period, so the ID gets allocated well before publishing

It sounds like this is possible with CVEs requested through GitHub Advisories as well. From the docs:

Requesting a CVE identification number doesn't make your security advisory public. If your security advisory is eligible for a CVE, GitHub will reserve a CVE identification number for your advisory. We'll then publish the CVE details after you make your security advisory public.

This blog post also says:

We share the CVE number with you while your advisory is still in draft, but we won’t publish anything until you make your GHSA public.

[dghgit]

Thanks for the information, I'll look into it.