On Thu, May 23, 2024 at 4:07 PM Marshall Clow via Boost < boost@lists.boost.org> wrote:

If I could remove them entirely, I would do so. But they appear to be an artifact of the tagging process.

Maybe this is something Sam could look into? Thanks

On Thu, May 23, 2024 at 4:22 PM Sam Darwin via Boost wrote:

...

If I could remove them entirely, I would do so. But they appear to be an artifact of the tagging process.

As Andrey said, they are not a mere artifact of tagging. They were purposely added, and maintained in the github actions script release-cmake.yml.

How about...maybe we can write a new script, a policeman of sorts who compares the release artifacts with the actual releases, and deletes any GitHub artifact which is not bitwise identical to an Official Release? This way it is guaranteed that all artifacts are in fact Actual Releases. Thanks

On 5/24/24 02:07, Marshall Clow wrote:

On May 23, 2024, at 3:50 PM, Andrey Semashev via Boost wrote:

...

Also, release tarballs on GitHub don't have hashsums or signatures attached.

https://github.com/boostorg/boost/issues/838 https://github.com/boostorg/boost/issues/838

As I wrote in that issue: The archives on GitHub are not official releases.

Please stop pretending/telling people that they are.

If I could remove them entirely, I would do so. But they appear to be an artifact of the tagging process.

They are not a mere artifact of tagging. They were purposely added - first, to help CMake users (CMake-targeted tarballs have a different file layout), then to fix issues with jfrog (the b2 archives are similar to those published on jfrog, but lack documentation). My understanding is that we're moving towards releases on GitHub.

Sorry - forgot to include the list in my reply.

Begin forwarded message:

From: Marshall Clow Subject: Re: [boost] OSTIF Boost security audit report Date: May 23, 2024 at 4:15:14 PM PDT To: boost@lists.boost.org

On May 23, 2024, at 4:10 PM, Andrey Semashev via Boost mailto:boost@lists.boost.org> wrote:

...

On 5/24/24 02:07, Marshall Clow wrote:

...

On May 23, 2024, at 3:50 PM, Andrey Semashev via Boost wrote:

...

Also, release tarballs on GitHub don't have hashsums or signatures attached.

https://github.com/boostorg/boost/issues/838 https://github.com/boostorg/boost/issues/838

As I wrote in that issue: The archives on GitHub are not official releases.

Please stop pretending/telling people that they are.

If I could remove them entirely, I would do so. But they appear to be an artifact of the tagging process.

They are not a mere artifact of tagging. They were purposely added - first, to help CMake users (CMake-targeted tarballs have a different file layout), then to fix issues with jfrog (the b2 archives are similar to those published on jfrog, but lack documentation).

Unless they’re identical to the published tarballs that we provide SHAs for, they should not be used. They’re not tested (among other things)

...

My understanding is that we're moving towards releases on GitHub.

That’s as may be, but we’ll deal with that then.

— Marshall

Andrey Semashev wrote:

On 5/24/24 02:07, Marshall Clow wrote:

...

As I wrote in that issue: The archives on GitHub are not official releases.

Please stop pretending/telling people that they are.

If I could remove them entirely, I would do so. But they appear to be an artifact of the tagging process.

They are not a mere artifact of tagging. They were purposely added

Correct, I added them.

- first, to help CMake users (CMake-targeted tarballs have a different file layout), then to fix issues with jfrog (the b2 archives are similar to those published on jfrog, but lack documentation).

I added the b2 archives so that people downloading Boost in CI jobs, especially from Github Actions, can use an archive that is smaller (because it contains no documentation, which isn't needed on CI), doesn't stress our primary downloads, and is much faster to download because it stays within the Github servers.