[Request]: security issues by double 1.4.36 tagging

[robUx4]

We (VLC) recently noticed the hash of the tagged 1.4.36 Header version has changed. We rely on the hash of tarballs to ensure that the code has not be altered maliciously.

After analysis it seems that the old 1.4.36 version (e584f0f791aa1999d9047455fbaf62d6519882c6266a9c1fd30fd4f7c392bb06be3157e53aabaa99ab1efac46e86365715a4dd44b16529f55eb3bf50931e8466) was incorrectly tagged as 1.4.36 as the Version.h is still 1.4.35.

There are plenty of code changes between the original 1.4.36 header tarball and the new 1.4.36 header tarball. But releasing the same version twice is not ideal. In the future please avoid this and use a different tarball name for any content that has changed in the tarball. The original 1.4.36 tarball was actually a 1.4.35 version so that's probably where the problem originated. However overwriting tarballs (I don't think they are generated by Github) should never happen.

Thanks in advance.

[rhutsAMD]

This was due to a workaround for day one support for AV1 B-frames in OBS. We were approved to release a subset of the 1.4.36 API ahead of schedule to allow public integration of AV1 B-frames encoding into OBS. The OBS folks deemed it necessary to update the AMF dependency upgrade in OBS to only stable releases so we labelled it as such, and have now relabelled to the full 1.4.36 release once the corresponding public driver was released. We appreciate the understanding of the dilemma and hope it did not cause much inconvenience.