Re: Limited security support for Go/Rust? Re ssh3

[Stephan Verbücheln]

Is rebuilding really the biggest problem? Even if Debian had enough
capacity to rebuild everything after the change of a build dependency,
I do not see how this solves the work of tracking Rust dependencies in
the first place.

I use a handful of Rust applications which I am building myself on
Debian. Each of them has hundreds of tiny dependencies which are
changing on a daily (if not hourly) basis. Some of them I can only
build in Sid, or I have to checkout really old commits from Git.
I do not see how this is supposed to be working in a Debian stable
release with all the required manual work such as backporting security
fixes etc.

Regards
Stephan


signature.asc
Description: This is a digitally signed message part

Re: Limited security support for Go/Rust? Re ssh3

[Paul Wise]

On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote:

> I asked for practical solutions, not theoretical ones.  We don't have a
> suitable way to rebuild all packages just because right now.

There are some ideas on the static linking wiki page:

https://wiki.debian.org/StaticLinking

Probably the most practical solution for today would be to use a build
info database to find out which builds had installed binary packages
containing insecure statically linkable files of any kind, then rebuild
the source packages that were affected. There is a 2019 demo here:

https://salsa.debian.org/bremner/builtin-pho/-/blob/master/demos/needs-rebuild.sh
https://www.cs.unb.ca/~bremner//blog/posts/builtin-pho/

This may mean rebuilding more packages than were really needed,
but a more exact method would require full tracing of input data to
output data during builds being added to all toolchains, which seems
like a much longer term project than buildinfo based rebuilds.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1060880: ITP: altdns -- Subdomain discovery through alterations and permutations

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: altdns
  Version : 1.0.2
  Upstream Contact: Shubham Shah 
* URL : https://github.com/infosec-au/altdns
* License : GPL-2.0
  Programming Lang: Python
  Description : Subdomain discovery through alterations and permutations

 This package contains a DNS recon tool that allows for the discovery of
 subdomains that conform to patterns. Altdns takes in words that could be
 present in subdomains under a domain (such as test, dev, staging) as well as
 takes in a list of subdomains that you know of.
 .
 From these two lists that are provided as input to altdns, the tool then
 generates a massive output of "altered" or "mutated" potential subdomains that
 could be present. It saves this output so that it can then be used by your
 favourite DNS bruteforcing tool.

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Russ Allbery]

Roger Lynn  writes:
> On 15/01/2024 18:00, Russ Allbery wrote:

>> When you have the case of an application that optionally wants to do foo,
>> a shared library that acts as a client, and a daemon that does foo, there
>> are three options:
>>
>> 1. Always install the shared library and daemon even though it's an
>>optional feature, because the shared library is a link dependency for
>>the application and the shared library viewed in isolation does require
>>the daemon be running to do anything useful.
>> 
>> 2. Weaken the dependency between the shared library and the daemon so that
>>the shared library can be installed without the daemon even though it's
>>objectively useless in that situation because it's the easiest and
>>least annoying way to let the application be installed without the
>>daemon, and that's the goal.  The shared library is usually tiny and
>>causes no problems by being installed; it just doesn't work.
>> 
>> 3. Weaken the dependency between the application and the shared library,
>>which means the application has to dynamically load the shared library
>>rather than just link with it.  This is in some ways the most "correct"
>>from a dependency perspective, but it's annoying to do, introduces new
>>error handling cases in the application, and I suspect often upstream
>>will flatly refuse to take such a patch.

> Unless I have misunderstood, I think you may have missed another option:

> 4. Let the leaf application declare the appropriate dependency on the
>daemon, because the application writer/packager is in the best position
>to know how important the functionality provided by the daemon is to the
>application. This could be considered to be option 2b, and a "suggests"
>dependency of the library on the daemon may still be appropriate.

I was thinking of this as a special case of 2, but yes, it's a
sufficiently common special case that it's worth calling out on its own.

I'm not sure that this whole discussion belongs in Policy because it's
very hard to make policy recommendations here without a lot of
case-specific details, but a section in the Developers Guide or some
similar resource about how to think about these cases seems like it might
be useful.  It does come up pretty regularly.

-- 
Russ Allbery (r...@debian.org)  

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Roger Lynn]

On 15/01/2024 18:00, Russ Allbery wrote:
> When you have the case of an application that optionally wants to do foo,
> a shared library that acts as a client, and a daemon that does foo, there
> are three options:
> 
> 1. Always install the shared library and daemon even though it's an
>optional feature, because the shared library is a link dependency for
>the application and the shared library viewed in isolation does require
>the daemon be running to do anything useful.
> 
> 2. Weaken the dependency between the shared library and the daemon so that
>the shared library can be installed without the daemon even though it's
>objectively useless in that situation because it's the easiest and
>least annoying way to let the application be installed without the
>daemon, and that's the goal.  The shared library is usually tiny and
>causes no problems by being installed; it just doesn't work.
> 
> 3. Weaken the dependency between the application and the shared library,
>which means the application has to dynamically load the shared library
>rather than just link with it.  This is in some ways the most "correct"
>from a dependency perspective, but it's annoying to do, introduces new
>error handling cases in the application, and I suspect often upstream
>will flatly refuse to take such a patch.

Unless I have misunderstood, I think you may have missed another option:

4. Let the leaf application declare the appropriate dependency on the
   daemon, because the application writer/packager is in the best position
   to know how important the functionality provided by the daemon is to the
   application. This could be considered to be option 2b, and a "suggests"
   dependency of the library on the daemon may still be appropriate.

As a user, I don't like option 1, and think it could result in packagers
being asked to provide heavy and light versions of their applications with
all their optional libraries linked or not. When installing new packages I
tend to assume that applications will have some sort of dependency on
daemons which are important to them.

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Simon McVittie]

On Mon, 15 Jan 2024 at 19:59:22 +0100, Johannes Schauer Marin Rodrigues wrote:
> Just today I had a case where I was building something innocent and suddenly I
> had an init system installed because:
> 
> libgtk-3-dev -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service \
>   -> dbus-session-bus -> dbus-user-session -> libpam-systemd -> systemd-sysv
> 
> I'm sure all of these packages have a very good reason to depend on the next
> one in the chain

Yes they do, you have rediscovered
https://lists.debian.org/debian-devel/2019/08/msg00278.html as mentioned
earlier in the thread.

Back in 2019, I felt that the project was demanding that I must find a way
to break that dependency chain, so I proposed a debhelper patch, which
was rejected. If this dependency chain is particularly objectionable to
you, please consider revisiting #934893 and advocating it better than I
was able to. One of the problems with feeling obliged to do work that I,
personally, don't believe is the right thing is that I'm never going to be
very effective at convincing others that they should accept that change.

smcv

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Ansgar (2024-01-07 20:39:57)
> I would like to extend Debian Policy on libraries depending on services
> (daemons) that they can speak to.
> 
> Let me bring to examples, one made up,, one for which I filed a bug
> recently. But as far as I can tell this question comes up from time to
> time:
> 
> 1. libpulse0 & friends
> --
> 
> libpulse0 is a client library for the Pulseaudio server. It doesn't do
> much without pulseaudio.
> 
> Q: Should libpulse0 have Depends: pulseaudio?
> 
> There a similar libraries like libjack0 to talk to Jackd.
> 
> Q: Should libjack0 have Depends: jackd1?
> 
> The answer should probably be the same for both questions.

another entry to the "it depends" that wasn't mentioned yet (I think) is build
dependencies. Shared libraries are pulled in by *-dev packages (libpulse-dev
and libjack-dev for above examples) but I guess there are only rare cases where
a service or daemon is required for building something and if it is, it is
probably not pulled in via any *-dev build dependencies but by an explicit
build dependency on the service.

So I think something to keep in mind during this discussion is, that any
changes to shared library dependencies will also change what build dependencies
ultimately get installed into the build chroot.

Just today I had a case where I was building something innocent and suddenly I
had an init system installed because:

libgtk-3-dev -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service \
  -> dbus-session-bus -> dbus-user-session -> libpam-systemd -> systemd-sysv

I'm sure all of these packages have a very good reason to depend on the next
one in the chain but my source package just wants libgtk-3-dev and not a full
blown init system in its build chroot.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Simon McVittie]

On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote:
> "Theodore Ts'o"  writes:
> > I'll argue that best practice is that upstream [should] make the shared
> > library useful *without* the daemon

Is the argument here that any design that separates into clients and a
non-optional server (for example to do privilege separation, or to mediate
indirect access to a non-shareable resource) is fundamentally flawed?
If yes, then goodbye to task-desktop, because X11 and Wayland are both
among the protocols that work like that.

I would personally like to see *more* privilege separation across IPC
boundaries rather than less, if that can reduce the total attack surface
of the setuid/setcap executables in the trusted computing base. I'm sure
you're one of a few developers in Debian who can successfully navigate
the hazards involved in writing a safe setuid executable without making
security-sensitive mistakes, but that puts you in a small group whose
limited time doesn't scale well.

On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote:
> 2. Weaken the dependency between the shared library and the daemon so that
>the shared library can be installed without the daemon even though it's
>objectively useless in that situation because it's the easiest and
>least annoying way to let the application be installed without the
>daemon, and that's the goal.

This is what we have typically done for sound servers (PulseAudio,
Pipewire, Jack and friends), for X11, for Wayland, and for optional uses
of D-Bus, among other frameworks where the separation into server and
client is sort of the point.

For uses of D-Bus that are important or essential to the application,
typically it is the application rather than the client library that
has a weak or strong dependency on {default-,}dbus-{system,session}-bus
and the appropriate service to talk to.

That works fine if the service we're talking to is something that
we expect "most" desktop environments to have pulled in somehow,
but the cost of that approach is that every component needs a plan
for how to cope with the server not being there. For instance, for
password storage (gnome-keyring, kwallet and other such things), the
fallback will typically be to write the password to a flat file that
will not be encrypted-at-rest (unless the sysadmin has taken steps to
use system-level encryption), which is a perfectly viable implementation
but seems non-ideal as a default.

smcv

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Gioele Barabucci]

On 15/01/24 18:58, Russ Allbery wrote:

When you have the case of an application that optionally wants to do foo,
a shared library that acts as a client, and a daemon that does foo, there
are three options:


From the point of view a Debian package there are four options: 
Depends:, Recommends:, Suggests:, Enhances:, [nothing].


Perhaps a fifth category is needed for this 
shared-library-that-talks-to-a-deamon scenarion.


Or the whole D/R/S system could be changed to be more explicit about why 
a package Depends: or Recommends: another one:


* LinksToLibrary (Depends:)
* UsesProgram (Depends:)
* UsesProgramInMaintscript (Pre-Depends:)
* TalksToDaemon (Depends:)
* TalksToDaemonIfAvailable (Recommends:/Suggests:)
* LoadsAtRuntimeIfAvailable (Recommends:/Suggests:)
* IsPluginFor (Enhances:)

Regards,

--
Gioele Barabucci

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Russ Allbery]

"Theodore Ts'o"  writes:

> I'll argue that best practice is that upstream show make the shared
> library useful *without* the daemon, but if the daemon is present,
> perhaps the shared library can do a better job.

Eh, I think this too depends on precisely what the shared library is for.
The obvious example of where this doesn't work is when the shared library
is a client for a local system service, and its entire point is to
dispatch calls to that service, but the library and service combined
implement an optional feature in some of the programs linked to it.

I think that's a relatively common case and the sort of case that provokes
most of the desire to not make shared libraries have hard dependencies on
their services.  There are a bunch of services that do not support (and
often would never reasonably support) network connections to their
underlying services.  An obvious example is a library and service pair
that represents a way to manage privilege escalation with isolation on the
local system.  You cannot make the shared library useful without the
daemon because the entire point of the shared library and daemon pair is
to not give those permissions to the process containing the shared
library.

When you have the case of an application that optionally wants to do foo,
a shared library that acts as a client, and a daemon that does foo, there
are three options:

1. Always install the shared library and daemon even though it's an
   optional feature, because the shared library is a link dependency for
   the application and the shared library viewed in isolation does require
   the daemon be running to do anything useful.

2. Weaken the dependency between the shared library and the daemon so that
   the shared library can be installed without the daemon even though it's
   objectively useless in that situation because it's the easiest and
   least annoying way to let the application be installed without the
   daemon, and that's the goal.  The shared library is usually tiny and
   causes no problems by being installed; it just doesn't work.

3. Weaken the dependency between the application and the shared library,
   which means the application has to dynamically load the shared library
   rather than just link with it.  This is in some ways the most "correct"
   from a dependency perspective, but it's annoying to do, introduces new
   error handling cases in the application, and I suspect often upstream
   will flatly refuse to take such a patch.

We do 2 a lot because it's pragmatic and it doesn't really cause any
practical problems, even though it technically means that we're not
properly representing the dependencies of the shared library.  We in
general try not to do 1 for reasons that I think are sound.  Minimizing
the footprint of applications for people who don't want optional features
is something that I personally value a lot in Debian.

-- 
Russ Allbery (r...@debian.org)  

Bug#1060853: ITP: golang-github-sigstore-protobuf-specs -- Sigstore Protocol Buffer code (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-sigstore-protobuf-specs
  Version : 0.2.1-1
  Upstream Author : sigstore
* URL : https://github.com/sigstore/protobuf-specs
* License : Apache-2.0
  Programming Lang: Go
  Description : Sigstore Protocol Buffer code (library)

 This repository holds protobuf specifications for Sigstore messages.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-sigstore-protobuf-specs

/Simon


signature.asc
Description: PGP signature

Bug#1060852: ITP: golang-bitbucket-creachadair-shell -- implements basic shell command-line splitting for Go (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-bitbucket-creachadair-shell
  Version : 0.0.8-1
  Upstream Author : Michael J. Fromberger
* URL : https://bitbucket.org/creachadair/shell/
* License : BSD-3-Clause
  Programming Lang: Go
  Description : implements basic shell command-line splitting for Go 
(library)

 Provides supports for splitting and joining of shell command strings.
 .
 The Split function divides a string into whitespace-separated fields,
 respecting single and double quotation marks as defined by the Shell Command
 Language section of IEEE Std 1003.1 2013.  The Quote function quotes
 characters that would otherwise be subject to shell evaluation, and the Join
 function concatenates quoted strings with spaces between them.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-bitbucket-creachadair-shell/

/Simon


signature.asc
Description: PGP signature

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Theodore Ts'o]

On Mon, Jan 08, 2024 at 11:18:09AM +, Simon McVittie wrote:
> On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote:
> > Maybe the question is also a bit .. "it depends".
> ...
> > So that users actually likely get a system that works?
> 
> I think the fact that we argue about this every few years, with no simple
> conclusion, is adequate evidence that the answer is "it depends". We're
> balancing two competing factors: "make the system work by default" implies
> that *something* needs to be responsible for pulling in required services
> at least some of the time, while "make the system flexible" implies that
> we should not be pulling in all of the services all of the time.

I'll argue that best practice is that upstream show make the shared
library useful *without* the daemon, but if the daemon is present,
perhaps the shared library can do a better job.

For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.

So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.

Of course, that's an upstream design consideration, and not all
upstreams are so forward looking... in their design.

> 
> Meanwhile, some distributions are more opinionated than Debian,
> have chosen a distro-wide preferred implementation for each swappable
> component, and make it quite difficult to exclude those components or
> swap them for alternatives. We probably don't want to do that either.

Well, right.  And if the distribution's primary market is enterprise
customers, such that using an Enterprise Resource Planning system is
highly likely (even if said ERP is proprietary softare sold by a very
large German company), you might decide that it's worthwhile to
install uuidd by default, especially since it's a relativelty small
daemon.  But if you're a distribution that thinks that every last
kilobyte matters, because you might be used in a docker context (for
example), then you mnight want to make different choices.

Cheers,

- Ted

Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: trillian
  Version : 1.6.0-1
  Upstream Author : Google
* URL : https://github.com/google/trillian
* License : Apache-2.0
  Programming Lang: Go
  Description : A transparent, highly scalable and cryptographically 
verifiable data store

 Trillian is an implementation of the concepts described in the
 Verifiable Data Structures (/docs/papers/VerifiableDataStructures.pdf)
 white paper, which in turn is an extension and generalisation of the
 ideas which underpin Certificate Transparency (https://certificate-
 transparency.org).
 .
 Trillian implements a Merkle tree
 (https://en.wikipedia.org/wiki/Merkle_tree) whose contents are served
 from a data storage layer, to allow scalability to extremely large
 trees.  On top of this Merkle tree, Trillian provides the following:
 .
  * An append-only **Log** mode, analogous to the original
Certificate Transparency (https://certificate-transparency.org) logs.
In
this mode, the Merkle tree is effectively filled up from the left,
giving a
*dense* Merkle tree.
 .
 Certificate Transparency (CT) (https://tools.ietf.org/html/rfc6962) is
 the most well-known and widely deployed transparency application, and an
 implementation of CT as a Trillian personality is available in the
 certificate-transparency-go repo (https://github.com/google/certificate-
 transparency-go/blob/master/trillian).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/trillian

/Simon


signature.asc
Description: PGP signature

Bug#1060841: ITP: golang-github-transparency-dev-merkle -- create and manipulate Merkle trees in Go (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-transparency-dev-merkle
  Version : 0.0.2-1
  Upstream Author : Pavel Kalinnikov, Al Cutter, Martin Hutchinson, M Hickford, 
et al
* URL : https://github.com/transparency-dev/merkle
* License : Apache-2.0
  Programming Lang: Go
  Description : create and manipulate Merkle trees in Go (library)

 Provides Go code to help create and manipulate Merkle trees, as well as
 constructing and verifying various types of proof.
 .
 This is the data structure which is used by projects such as Trillian
 (https://github.com/google/trillian) to provide verifiable logs
 (https://transparency.dev/verifiable-data-structures/#verifiable-log).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-transparency-dev-merkle

/Simon


signature.asc
Description: PGP signature

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-k8s-sigs-release-utils
  Version : 0.7.7-1
  Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/release-utils
* License : Apache-2.0
  Programming Lang: Go
  Description : utilities for kubernetes Go release engineering (library)

 Tiny utilities for use by the Release Engineering subproject and
 kubernetes/release (https://github.com/kubernetes/release/).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-k8s-sigs-release-utils

/Simon


signature.asc
Description: PGP signature

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-adamkorcz-go-fuzz-headers-1
  Version : 0.0~git20230919.8b5d3ce-1
  Upstream Author : Adam Korcz 
* URL : https://github.com/AdamKorcz/go-fuzz-headers-1
* License : Apache-2.0
  Programming Lang: Go
  Description : helper functions for Go fuzzing (library)

 Various helper functions for go fuzzing. It is mostly used in combination
 with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with
 fuzzing in the standard library will also be supported. Any coverage guided
 fuzzing engine that provides an array or slice of bytes can be used with
 go-fuzz-headers.
 .
 go-fuzz-headers' approach to fuzzing structs is strongly inspired by
 gofuzz (https://github.com/google/gofuzz).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/

/Simon


signature.asc
Description: PGP signature

Bug#1060836: ITP: golang-github-cavaliergopher-rpm -- A Go implementation of the RPM file format

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-cavaliergopher-rpm
  Version : 1.2.0-1
  Upstream Author : Ryan Armstrong, et al
* URL : https://github.com/cavaliergopher/rpm
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go implementation of the RPM file format (library)

 This implements the rpm package file format as a Go library
 .
 See the package documentation
 (https://pkg.go.dev/github.com/cavaliergopher/rpm) to get started.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-cavaliergopher-rpm

/Simon


signature.asc
Description: PGP signature

Bug#1060834: ITP: golang-github-veraison-go-cose -- go library for CBOR Object Signing and Encryption (COSE)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-veraison-go-cose
  Version : 1.2.1-1
  Upstream Author : Veraison
* URL : https://github.com/veraison/go-cose
* License : MPL-2.0
  Programming Lang: Go
  Description : go library for CBOR Object Signing and Encryption (COSE)

 A golang library for the COSE specification
 (https://datatracker.ietf.org/doc/rfc9052/)

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-veraison-go-cose

/Simon


signature.asc
Description: PGP signature

Re: Limited security support for Go/Rust? Re ssh3

[Bastian Blank]

On Sun, Jan 14, 2024 at 04:24:57PM +0100, Simon Josefsson wrote:
> Isn't that what the text refers to?  Vendoring and static linking are
> two examples of the same problem that the security team may encounter.

We accept vendoring of autoconf/automake/gnulib distro wide.  Please
show practical problems with it?  The result of autoconf and automake is
not embedded into the produced binaries, so a security vulnerability can
not go on.  The vendoring of gnulib, well, is old and maybe you could
show that it is a problem in the sources that have it, aka they don't
handle security fixes and at the same time don't change the library.

> The problem with dependencies are more obvious for Go/Rust code but I
> think we always have had that problem anyway.

Here the problem is embedded into the language oekosystem itself.  It is
not a choice of the software author to do static linking.

> As for solutions, isn't the solution to both vendoring or statical
> linking the obvious one?  You will have to rebuild all packages that
> contain the security vulnerability.

I asked for practical solutions, not theoretical ones.  We don't have a
suitable way to rebuild all packages just because right now.

> Maybe I'm missing how these two problems result in different problems
> for the security team?

You did not show that autoconf/automak/gnulib is a problem at all.  And
a => b with a false gives no answer.

Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.