[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: security updates of Golang packages



On Mon, Apr 25, 2022 at 1:30 AM Thorsten Alteholz <debian@alteholz.de> wrote:
>
> 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 binNMU, it's also possible to add Dep-Wait.

I don't have a preference for it. And I think binNMU is not friendly
to Debian derivatives.

> >>
> >> 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.
>

But they are different.

For ratt and other packages focusing on Build-Depends, they ensure
other packages won't FTBFS.
For tools focusing on (Static-)Built-Using, they ensure the embedded
libraries are up to date.

The key difference is the testing dependencies. They are not embedded
in binary. So (Static-)Built-Using doesn't record them.
And there are also transitive dependencies. For example, A depends B
and C. X depends A. X may only embed A and B, not C.

For security rebuild, there is no need to rebuild for these cases.

> >>
> >> 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
>

-- 
Shengjing Zhu


Reply to: