Re: Go issues wrt. Debian infrastructure: moving forward

[Paul Gevers]

Hi,

On 31-01-2021 18:43, Shengjing Zhu wrote:
> It might be the time to resume the discussion...

> Dear ftpmaster, will the task that imports all sources to
> security-master be ready for bullseye?

I think this is a fair question. What's the status on the archive side
of things? (A "no" or "depends on $something" is also an answer).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Go issues wrt. Debian infrastructure: moving forward

[Shengjing Zhu]

Hi,

It might be the time to resume the discussion...

On Sun, Aug 30, 2020 at 2:09 AM Ansgar  wrote:
>
> Hi,
>
> Clément Hermann writes:
> > The original message on debian-go and debian-release is here:
> >
> > https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org
>
> For the ftp-master side, I wanted to just import all sources from a
> stable release into security-master (in a private archive).  dak can
> then use these when binNMUs arrive, for Built-Using, or when people
> upload without the .orig.tar.gz included.  The second part should
> already work.
>
> There are currently two issues with this:
>
> - security-master.d.o should get more disk space.
>   Maybe we should get a (new) physical host for security-master that
>   provides this?  It should probably be a physical host and not a VM to
>   allow using a YubiKey (or similar) for the signing key.
>
> - Time. I currently don't have much to spend on Debian.
>
> Are there more issues that ftp-master would have to deal with?
>

Dear ftpmaster, will the task that imports all sources to
security-master be ready for bullseye?

-- 
Shengjing Zhu

Re: Go issues wrt. Debian infrastructure: moving forward

[Adrian Bunk]

On Mon, Aug 31, 2020 at 08:37:05PM +0200, Emilio Pozuelo Monfort wrote:
> On 31/08/2020 20:29, Moritz Mühlenhoff wrote:
> > On Sat, Aug 29, 2020 at 10:18:57PM +0200, Clément Hermann wrote:
> >> Other than that, I don't think there are, my understanding was that the
> >> missing orig.tar.gz when dealing with a lot of new packages in the
> >> security archive was the main blocker on ftp-master plate.
> > 
> > I think so, too. That should resolve the tooling issues and only leave
> > the implementation of how to detect what needs to be rebuilt.
> 
> For that, take a look at the tool generating the haskell and ocaml binNMU 
> list,
> see [1] and [2] and the source in [3]. You may want to contribute and extend
> that tool to support golang, or at least reuse the output format (both the
> wanna-build and the json one).

The packages that do *not* get rebuilt during transitions of ecosystems 
that are based on static libraries like Haskell are the actual programs
like git-annex. Transitions only handle dependencies between static
libraries.

And the problem is a bit different for ecosystems where libraries are 
static libraries, and ecosystems where "libraries" are binary-all
packages like Go.

For a security fix in code shipped by the Haskell compiler a 26 level
transition involving 1k package is necessary in stable.

For a security fix in the package shipped with Go compiler[1] it is 
sufficient to just binNMU the 100 leaf packages containing programs 
written in Go.

> Cheers,
> Emilio
> 
> [1] https://people.debian.org/~nomeata/binNMUs-haskell.txt
> [2] https://people.debian.org/~nomeata/binNMUs-ocaml.txt
> [3] https://salsa.debian.org/haskell-team/tools/-/tree/master/binnmus

cu
Adrian

[1] think of it like glibc and OpenSSL shipped with gcc
and statically linked into all applications

Re: Go issues wrt. Debian infrastructure: moving forward

[Emilio Pozuelo Monfort]

On 31/08/2020 20:29, Moritz Mühlenhoff wrote:
> On Sat, Aug 29, 2020 at 10:18:57PM +0200, Clément Hermann wrote:
>> Other than that, I don't think there are, my understanding was that the
>> missing orig.tar.gz when dealing with a lot of new packages in the
>> security archive was the main blocker on ftp-master plate.
> 
> I think so, too. That should resolve the tooling issues and only leave
> the implementation of how to detect what needs to be rebuilt.

For that, take a look at the tool generating the haskell and ocaml binNMU list,
see [1] and [2] and the source in [3]. You may want to contribute and extend
that tool to support golang, or at least reuse the output format (both the
wanna-build and the json one).

Cheers,
Emilio

[1] https://people.debian.org/~nomeata/binNMUs-haskell.txt
[2] https://people.debian.org/~nomeata/binNMUs-ocaml.txt
[3] https://salsa.debian.org/haskell-team/tools/-/tree/master/binnmus

Re: Go issues wrt. Debian infrastructure: moving forward

[Moritz Mühlenhoff]

On Sat, Aug 29, 2020 at 10:18:57PM +0200, Clément Hermann wrote:
> Hi,
> 
> On 29/08/2020 20:09, Ansgar wrote:
> > Hi,
> > 
> > Clément Hermann writes:
> >> The original message on debian-go and debian-release is here:
> >>
> >> https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org
> > 
> > For the ftp-master side, I wanted to just import all sources from a
> > stable release into security-master (in a private archive).  dak can
> > then use these when binNMUs arrive, for Built-Using, or when people
> > upload without the .orig.tar.gz included.  The second part should
> > already work.
> > 
> > There are currently two issues with this:
> > 
> > - security-master.d.o should get more disk space.
> >   Maybe we should get a (new) physical host for security-master that
> >   provides this?  It should probably be a physical host and not a VM to
> >   allow using a YubiKey (or similar) for the signing key.
> 
> Is there a way one can help on this?

Maybe open a ticket with DSA to discuss options for extending disk space
with or without a physical machine?

> Other than that, I don't think there are, my understanding was that the
> missing orig.tar.gz when dealing with a lot of new packages in the
> security archive was the main blocker on ftp-master plate.

I think so, too. That should resolve the tooling issues and only leave
the implementation of how to detect what needs to be rebuilt.

Cheers,
Moritz

Re: Go issues wrt. Debian infrastructure: moving forward

[Clément Hermann]

Hi,

On 29/08/2020 20:09, Ansgar wrote:
> Hi,
> 
> Clément Hermann writes:
>> The original message on debian-go and debian-release is here:
>>
>> https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org
> 
> For the ftp-master side, I wanted to just import all sources from a
> stable release into security-master (in a private archive).  dak can
> then use these when binNMUs arrive, for Built-Using, or when people
> upload without the .orig.tar.gz included.  The second part should
> already work.
> 
> There are currently two issues with this:
> 
> - security-master.d.o should get more disk space.
>   Maybe we should get a (new) physical host for security-master that
>   provides this?  It should probably be a physical host and not a VM to
>   allow using a YubiKey (or similar) for the signing key.

Is there a way one can help on this?

> - Time. I currently don't have much to spend on Debian.

> Are there more issues that ftp-master would have to deal with?

As we discussed on IRC, once we (go team) have decided on the way to
store the information about embedded packages, we might need a new
ad-hoc request on dacweb.

Other than that, I don't think there are, my understanding was that the
missing orig.tar.gz when dealing with a lot of new packages in the
security archive was the main blocker on ftp-master plate.

But if anyone think about something, now would be a great time to chime
in ;)

Cheers,

-- 
nodens

Re: Go issues wrt. Debian infrastructure: moving forward

[Ansgar]

Hi,

Clément Hermann writes:
> The original message on debian-go and debian-release is here:
>
> https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org

For the ftp-master side, I wanted to just import all sources from a
stable release into security-master (in a private archive).  dak can
then use these when binNMUs arrive, for Built-Using, or when people
upload without the .orig.tar.gz included.  The second part should
already work.

There are currently two issues with this:

- security-master.d.o should get more disk space.
  Maybe we should get a (new) physical host for security-master that
  provides this?  It should probably be a physical host and not a VM to
  allow using a YubiKey (or similar) for the signing key.

- Time. I currently don't have much to spend on Debian.

Are there more issues that ftp-master would have to deal with?

Ansgar

Re: Go issues wrt. Debian infrastructure: moving forward

[Clément Hermann]

Hi, and thanks for your input Moritz, that's really helpful.

On 28/08/2020 19:48, Moritz Mühlenhoff wrote:
> On Thu, Aug 27, 2020 at 07:16:19PM +0200, Clément Hermann wrote:
>> I'm fine with IRC too. I think the dak implementation would be the best
>> (along with a script or something that can tell which packages to
>> binNMU, but with the proper field set d/control for binaries that
>> doesn't sound difficult).
>>
>> What I'd hope to get from such a session would be possible, acceptable
>> workaround if the dak issue is (as it seems) too complicated to fix in a
>> timely manner.
> 
> I think only FTP masters have the necessary insight to answer that.

By "that", do you mean determining if the dak issue is too complicated
or not to fix, or what would be an acceptable workaround for it ?


> The important thing is that in end binNMUs are made, a script which
> in the end performs sourceful uploads would cause too much churn.

Agreed, if that needs to happen is has to be as temporary workaround.

>> For instance, a script that would get all the needed source package and
>> upload then whenever someone needs to binNMU a go package. Or whatever
>> makes security@d.o and release management life easier.
> 
> Ideally we'd have a script which accepts a source package name as a parameter
> and the distro to target (like buster or unstable). The output should be
> a list of wanna build commands, like
> 
> wb nmu $SOURCEPKG . ANY . $DISTRO . - "Rebuild for $REASON"

Would it make sense to (optionnaly) provide a version for the source
package as well ? The script would then look for packages including the
code with that version or lower. If that's not needed, it's simpler, but
it should be possible.

I'm currently trying to come up with the best way to get the info needed
to get the wanted output.

My initial plan was to have a binary package control field, something
along the lines of XB-X-Go-Built-Using.

It made sense to me, because of the current (mis)usage of Built-Using in
Go packages.

However, if we start from the source package, it might makes more sense
to use a source paragraph custom field, say, something like this:

XS-Go-Built-Using: 

The name isn't great in this case (well you do build a source package,
but still), I'm open to suggestions ;)

The idea is to have a new ad-hoc request in dacweb
(api.ftp-master.debian.org) that will allow to have a json with all
packages having this field set, ordered by Suite.

Then  I guess it's a matter of parsing the fields to detect wich source
packages are using the package we want to replace, and then do it again
with those packages, until nothing is found (this is going to be some
fun algorithm writing, ideas and suggestions very welcome).


> I think there might be staggered build steps. Like when liba gets binNMUd
> and then libb (which uses liba) needs the same. So ideally the order of
> wb commands emitted should reflect that.

Yes. Hopefully we can come up with something that will avoid to much of
trial and error.


> With that setup in place, supporting Go and Rust updates in stable (and
> the same tool will also be useful in unstable!) should be fine. Shared
> libs would ofc be preferable, but withful thinking doesn't help us either :-)

:)

Cheers,

-- 
nodens

Re: Go issues wrt. Debian infrastructure: moving forward

[Moritz Mühlenhoff]

On Thu, Aug 27, 2020 at 07:16:19PM +0200, Clément Hermann wrote:
> I'm fine with IRC too. I think the dak implementation would be the best
> (along with a script or something that can tell which packages to
> binNMU, but with the proper field set d/control for binaries that
> doesn't sound difficult).
> 
> What I'd hope to get from such a session would be possible, acceptable
> workaround if the dak issue is (as it seems) too complicated to fix in a
> timely manner.

I think only FTP masters have the necessary insight to answer that.

The important thing is that in end binNMUs are made, a script which
in the end performs sourceful uploads would cause too much churn.

> For instance, a script that would get all the needed source package and
> upload then whenever someone needs to binNMU a go package. Or whatever
> makes security@d.o and release management life easier.

Ideally we'd have a script which accepts a source package name as a parameter
and the distro to target (like buster or unstable). The output should be
a list of wanna build commands, like

wb nmu $SOURCEPKG . ANY . $DISTRO . - "Rebuild for $REASON"

I think there might be staggered build steps. Like when liba gets binNMUd
and then libb (which uses liba) needs the same. So ideally the order of
wb commands emitted should reflect that.

With that setup in place, supporting Go and Rust updates in stable (and
the same tool will also be useful in unstable!) should be fine. Shared
libs would ofc be preferable, but withful thinking doesn't help us either :-)

Cheers,
Moritz

Re: Go issues wrt. Debian infrastructure: moving forward

[Clément Hermann]

Hi
On 27/08/2020 18:41, Moritz Muehlenhoff wrote:
> On Thu, Aug 27, 2020 at 11:31:36AM +0200, Clément Hermann wrote:
> On Wed, Aug 26, 2020 at 12:39:36PM +0200, Clément Hermann wrote:
> > - a way for dak to get the orig tarball from main archive when
> it's not
> > already in the security archive (or at least, as a workaround, a
> way to
> > find and upload all needed source easily)
>
> As soon as you stop emitting Built-Using, this problem is gone.  
> Except
> of course for the cases that actually needs them, which is mainly GPL
> and Apache licensed software.
> 
> It is still needed even if you stop using Built-Using. If a Go library is 
> updated
> (and similar for Rust) reverse dependencies needs to be rebuilt and 
> security-master
> and ftp-master don't share tarballs. The first time a package is built for a
> suite (e.g. buster-security) it currently needs an uplaod with includes the
> orig tarball (i.e. building with -sa).
> 
> Obviously this doesn't scale at all for binNMUing lots of rdeps. So we need
> a fix in dak/security-master so that it fetches the orig source from 
> ftp-master
> (or a similar solution).

Thanks for the confirmation :)

> Quoting from the original mail:
>> Can we take opportunity of Debconf20 to set up an ad-hoc session and
>> talk about the best way forward to fix this ?
> 
> I think an IRC session would work best, but not sure what exact input you 
> need?
> For dak implementation questions this needs some FTP master input.


I'm fine with IRC too. I think the dak implementation would be the best
(along with a script or something that can tell which packages to
binNMU, but with the proper field set d/control for binaries that
doesn't sound difficult).

What I'd hope to get from such a session would be possible, acceptable
workaround if the dak issue is (as it seems) too complicated to fix in a
timely manner.

For instance, a script that would get all the needed source package and
upload then whenever someone needs to binNMU a go package. Or whatever
makes security@d.o and release management life easier.

Cheers,

-- 
nodens

Re: Go issues wrt. Debian infrastructure: moving forward

[Moritz Muehlenhoff]

On Thu, Aug 27, 2020 at 11:31:36AM +0200, Clément Hermann wrote:
> >>> On Wed, Aug 26, 2020 at 12:39:36PM +0200, Clément Hermann wrote:
> >>> > - a way for dak to get the orig tarball from main archive when
> >>> it's not
> >>> > already in the security archive (or at least, as a workaround, a
> >>> way to
> >>> > find and upload all needed source easily)
> >>>
> >>> As soon as you stop emitting Built-Using, this problem is gone.  
> >>> Except
> >>> of course for the cases that actually needs them, which is mainly GPL
> >>> and Apache licensed software.

It is still needed even if you stop using Built-Using. If a Go library is 
updated
(and similar for Rust) reverse dependencies needs to be rebuilt and 
security-master
and ftp-master don't share tarballs. The first time a package is built for a
suite (e.g. buster-security) it currently needs an uplaod with includes the
orig tarball (i.e. building with -sa).

Obviously this doesn't scale at all for binNMUing lots of rdeps. So we need
a fix in dak/security-master so that it fetches the orig source from ftp-master
(or a similar solution).

Quoting from the original mail:
> Can we take opportunity of Debconf20 to set up an ad-hoc session and
> talk about the best way forward to fix this ?

I think an IRC session would work best, but not sure what exact input you need?
For dak implementation questions this needs some FTP master input.

Cheers,
Moritz

Re: Go issues wrt. Debian infrastructure: moving forward

[Clément Hermann]

On 27/08/2020 09:47, Paul Gevers wrote:
> Hi,
> 
> On 26-08-2020 13:40, Clément Hermann wrote:
>> On 26/08/2020 13:22, Reinhard Tartler wrote:
>>>
>>>
>>> On Wed, Aug 26, 2020 at 7:09 AM Bastian Blank >> > wrote:
>>>
>>> Hi Clement
>>>
>>> On Wed, Aug 26, 2020 at 12:39:36PM +0200, Clément Hermann wrote:
>>> > - a way for dak to get the orig tarball from main archive when
>>> it's not
>>> > already in the security archive (or at least, as a workaround, a
>>> way to
>>> > find and upload all needed source easily)
>>>
>>> As soon as you stop emitting Built-Using, this problem is gone.  Except
>>> of course for the cases that actually needs them, which is mainly GPL
>>> and Apache licensed software.
>>>
>>> That's surprising, it seems I must be missing some specifics about how
>>> dak handles Built-Using specifically. I skimmed through the dak source
>>> code, but nothing strikes out to me specifically about this particular
>>> point.
>>>
>>> can you please help me fill in the gaps here?
>>
>> I have to admit I don't really get it either. We will migrate away from
>> Built-Using, probably using something like rust is using
>> (X-Go-Built-Using). However, packages are still built statically, and
>> still need to be binNMUed when a build-depends has a security update.
>>
>> Did I misunderstand the issue with dak and orig tarballs not in security
>> archive yet?
>>
>> (note: adding back the CC-ed list, sorry for cross posting but this
>> still belong at least in debian-release IMO)
> 
> Well, I would say slightly more on the security (they can't decently
> support packages in the golang ecosystem) and ftp-master (the owners of
> dak and technically needed to solve the issue) lists, but yes, in the
> end it's the release team that decides what goes into the release. This
> problem is big one.

Right. Let me re-add t...@security.debian.org and add ftp-master then.

The original message on debian-go and debian-release is here:

https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org

Let's discuss this! we (go team) would love to work toward resolving this issue 
for Bullseye, but we can't decide what'd be better on our own - I'm sure no one 
is happy with the situation, and the ideal situation where Go packages don't 
need to statically link everything isn't likely to happen.

A meeting during DebConf with interested parties would be best in my opinion, 
but discussing things by e-mail is still good. :)

PS: but then maybe we should stick this to one list once interested parties 
have been notified, please let me know what the proper etiquette is on this 
matter since I have little to no experience on it
-- 
nodens

Re: Go issues wrt. Debian infrastructure: moving forward

[Paul Gevers]

Hi,

On 26-08-2020 13:40, Clément Hermann wrote:
> On 26/08/2020 13:22, Reinhard Tartler wrote:
>>
>>
>> On Wed, Aug 26, 2020 at 7:09 AM Bastian Blank > > wrote:
>>
>> Hi Clement
>>
>> On Wed, Aug 26, 2020 at 12:39:36PM +0200, Clément Hermann wrote:
>> > - a way for dak to get the orig tarball from main archive when
>> it's not
>> > already in the security archive (or at least, as a workaround, a
>> way to
>> > find and upload all needed source easily)
>>
>> As soon as you stop emitting Built-Using, this problem is gone.  Except
>> of course for the cases that actually needs them, which is mainly GPL
>> and Apache licensed software.
>>
>> That's surprising, it seems I must be missing some specifics about how
>> dak handles Built-Using specifically. I skimmed through the dak source
>> code, but nothing strikes out to me specifically about this particular
>> point.
>>
>> can you please help me fill in the gaps here?
> 
> I have to admit I don't really get it either. We will migrate away from
> Built-Using, probably using something like rust is using
> (X-Go-Built-Using). However, packages are still built statically, and
> still need to be binNMUed when a build-depends has a security update.
> 
> Did I misunderstand the issue with dak and orig tarballs not in security
> archive yet?
> 
> (note: adding back the CC-ed list, sorry for cross posting but this
> still belong at least in debian-release IMO)

Well, I would say slightly more on the security (they can't decently
support packages in the golang ecosystem) and ftp-master (the owners of
dak and technically needed to solve the issue) lists, but yes, in the
end it's the release team that decides what goes into the release. This
problem is big one.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Go issues wrt. Debian infrastructure: moving forward

[Clément Hermann]

On 26/08/2020 13:22, Reinhard Tartler wrote:
> 
> 
> On Wed, Aug 26, 2020 at 7:09 AM Bastian Blank  > wrote:
> 
> Hi Clement
> 
> On Wed, Aug 26, 2020 at 12:39:36PM +0200, Clément Hermann wrote:
> > - a way for dak to get the orig tarball from main archive when
> it's not
> > already in the security archive (or at least, as a workaround, a
> way to
> > find and upload all needed source easily)
> 
> As soon as you stop emitting Built-Using, this problem is gone.  Except
> of course for the cases that actually needs them, which is mainly GPL
> and Apache licensed software.
> 
> That's surprising, it seems I must be missing some specifics about how
> dak handles Built-Using specifically. I skimmed through the dak source
> code, but nothing strikes out to me specifically about this particular
> point.
> 
> can you please help me fill in the gaps here?

I have to admit I don't really get it either. We will migrate away from
Built-Using, probably using something like rust is using
(X-Go-Built-Using). However, packages are still built statically, and
still need to be binNMUed when a build-depends has a security update.

Did I misunderstand the issue with dak and orig tarballs not in security
archive yet?

(note: adding back the CC-ed list, sorry for cross posting but this
still belong at least in debian-release IMO)

-- 
nodens

Go issues wrt. Debian infrastructure: moving forward

[Clément Hermann]

Hi all,

Reinhard (CC-ed) and I have been briefly discussing the Go ecosystem
issue wrt. Debian Infrastructure.

We still need to find the best way to make go packages easier on
security team and release team.

Those issues have been summarized in
https://lists.debian.org/debian-go/2020/01/msg00060.html

as I understanding, we need two things:

- a way to find which packages have to be binNMUed
- a way for dak to get the orig tarball from main archive when it's not
already in the security archive (or at least, as a workaround, a way to
find and upload all needed source easily)

Can we take opportunity of Debconf20 to set up an ad-hoc session and
talk about the best way forward to fix this ?

Let's try to fix this once and for all! :)

Cheers,

-- 
nodens