Hi, On 24.04.22 15:21, Shengjing Zhu wrote:
Do you want to 1. Rebuild package to carry fixed CVE in dependencies 2. Fix CVE in library and then go through 1
I first fix the CVE in the affected package and than look at the list of packages that use it directly or via some kind of dependency chain. As there might be lots of packages in that list and one can easily mix the correct order of uploads, I also change the corresponding Dependency: to the latest version. So it is not just a binNMU, as I really change at least debian/control of each package.
For 1, I think you don't need to use the Build-Depends field which is used by ratt, or build-rdeps tool. We use Built-Using field, which records the static linked package. (We will move to a new field called Static-Built-Using, but it hasn't happened yet).
Yes, but I wanted to rely on an existing tool to get the list of affected packages. So if anything changes, it just has to be changed at one place.
For 1, do you want to no-change rebuild upload like Ubuntu, or do you want to give a list of packages to Release Team to schedule binMNU?
Due to the changed dependencies, it is not just a binNMU, so I guess that I have to do "normal" stable/unstable updates via PU-bugs. I already asked the Release Team how they would like to handle this.
Forget to mention that if you want to do binNMU, there are problems to do it on security-master. IIRC, it's because security-master doesn't have all the source tarballs. And this needs ftp-master to help.
Yes, that is the least of my problems :-).
I heard that for bullseye, ftp-master will copy all source tarballs to security-master by hand. But I also heard that the server for security-master lacks disk space. I'm not sure what's the current situation.
This problem still exists and it is not enough space for a copy of the whole archive. As the golang packages are not that large, the available space should last some time, though.
Thorsten