On 2024-01-25 17:10, Russ Allbery wrote:
Rebuilding a bunch of software after a security fix is not a completely
intractable problem that we have no idea how to even approach. It's
just
CPU cycles and good metadata plus ensuring that our software can be
rebuilt, something that we already promi
On Wed, Jan 24, 2024 at 09:37:27AM +0100, Simon Josefsson wrote:
> Simon Josefsson writes:
>
> >> > My naive approach on how to fix a security problem in package X
> >> > which is
> >> > statically embedded into other packages A, B, C, ... would be to
> >> > rebuild
> >> > the transitive closure
On Thu, Jan 25, 2024 at 07:03:05PM +, Luca Boccassi wrote:
> On Thu, 25 Jan 2024 at 18:22, Gard Spreemann wrote:
> >
> > Hello.
> >
> > Paul Wise writes:
> >
> > > On Thu, 2024-01-25 at 00:24 +, Wookey wrote:
> > >
> > >> People keep telling us (@ARM) how marvellous Rust is, and we keep
>
On Thu, 25 Jan 2024 at 18:22, Gard Spreemann wrote:
>
> Hello.
>
> Paul Wise writes:
>
> > On Thu, 2024-01-25 at 00:24 +, Wookey wrote:
> >
> >> People keep telling us (@ARM) how marvellous Rust is, and we keep
> >> telling them that it's useless in the real world until it sorts out
> >> the
On Thu, 25 Jan 2024 at 16:11, Russ Allbery wrote:
>
> Simon Josefsson writes:
>
> > I want to explore if there is a possibility to change status quo, and
> > what would be required to do so.
>
> > Given how often gnulib is vendored for C code in Debian, and other
> > similar examples, I don't thi
Simon Josefsson writes:
> I want to explore if there is a possibility to change status quo, and
> what would be required to do so.
> Given how often gnulib is vendored for C code in Debian, and other
> similar examples, I don't think of this problem as purely a Go/Rust
> problem. The parallel a
Hello.
Paul Wise writes:
> On Thu, 2024-01-25 at 00:24 +, Wookey wrote:
>
>> People keep telling us (@ARM) how marvellous Rust is, and we keep
>> telling them that it's useless in the real world until it sorts out
>> the stable ABI/dynamic linking problem.
>
> IIRC that has been worked on fo
On Jan 25, Wookey wrote:
> Luca is quite right here. Ultimately this can only be fixed by these
> ecosystems understanding that software in these languages cannot be
> sensibly used in distributions until they support modularity and
> stability. The rust people make the excuse that they are 'too
On Thu, 2024-01-25 at 00:24 +, Wookey wrote:
> People keep telling us (@ARM) how marvellous Rust is, and we keep
> telling them that it's useless in the real world until it sorts out
> the stable ABI/dynamic linking problem.
IIRC that has been worked on for some years now, and IIRC
the static
On 2024-01-24 13:29 +0100, Simon Josefsson wrote:
> Luca Boccassi writes:
>
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distributions model
Luca is quite right here. Ultimately this can only be fixed by these
ecosystems
On Jan 24, Peter Pentchev wrote:
> This might be a minority, optimistic, rose-tinted-glasses kind of
> opinion, but I believe that the state of the Rust ecosystem today
> (I have no experience with the Go one) is quite similar to what Perl and
> Python modules were 25, 20, bah, even 15 years ago.
[follow-ups should probably go to -project, but I'm not setting my
headers to try to force that]
At 2024-01-24T16:57:06+0100, Simon Josefsson wrote:
> One could equally well make the argument that distributors should care
> about the Go/Rust ecosystems, and make whatever changes needed in
> order
On Wed, Jan 24, 2024 at 01:01:34PM +, Luca Boccassi wrote:
> On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues
> wrote:
> >
> > Hi,
> >
> > Quoting Luca Boccassi (2024-01-24 12:59:38)
> > > There's always option B: recognize that the Rust/Go ecosystems are not
> > > designed to be
Luca Boccassi writes:
> On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote:
>>
>> Luca Boccassi writes:
>>
>> >> Having reflected a bit, and learned through my own experience and
>> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> >> to update my proposal on how to
On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote:
>
> Luca Boccassi writes:
>
> >> Having reflected a bit, and learned through my own experience and
> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
> >> to update my proposal on how to handle a security bug in any Go
On 2024-01-24 13:26:49 +0100 (+0100), Johannes Schauer Marin Rodrigues wrote:
[...]
> how does that work for those applications that require rust, go
> and friends? Are you proposing that everything that needs them
> should be be distributed by a flatpak or similar mechanism
> instead?
>
> Just a
On 24/01/24 14:01, Luca Boccassi wrote:
how does that work for those applications that require rust, go and friends?
Are you proposing that everything that needs them should be be distributed by a
flatpak or similar mechanism instead?
Those applications are not shipped in the distribution. If s
On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-01-24 12:59:38)
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distributions model, and are
> > instead
> > design
On 24/01/24 5:59 pm, Simon Josefsson wrote:
Does anyone know of a shared library in a Debian package written in Go?
I've only encountered the vendored approach to ship Go libraries.
libgovarnam1 is shipped as a shared library
https://packages.debian.org/sid/amd64/libgovarnam1/filelist
Open
Luca Boccassi writes:
>> Having reflected a bit, and learned through my own experience and
>> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> to update my proposal on how to handle a security bug in any Go/Rust/etc
>> package and the resulting package rebuilds:
>
> Ther
Hi,
Quoting Luca Boccassi (2024-01-24 12:59:38)
> There's always option B: recognize that the Rust/Go ecosystems are not
> designed to be compatible with the Linux distributions model, and are instead
> designed to be as convenient as possible for a _single_ application developer
> and its users -
On Wed, 24 Jan 2024 at 11:42, Simon Josefsson wrote:
>
> Simon Josefsson writes:
>
> >> > My naive approach on how to fix a security problem in package X
> >> > which is
> >> > statically embedded into other packages A, B, C, ... would be to
> >> > rebuild
> >> > the transitive closure of all pac
On 24/01/24 2:07 pm, Simon Josefsson wrote:
Yes, for a low-level Go package (e.g., golang-golang-x-net-dev), this
will mean rebuilding almost all of the Go packages in Debian and publish
them in a security advisory.
This algorithm can be optimized (i.e., reduce the number of packages to
publis
Simon Josefsson writes:
>> > My naive approach on how to fix a security problem in package X
>> > which is
>> > statically embedded into other packages A, B, C, ... would be to
>> > rebuild
>> > the transitive closure of all packages that Build-Depends on X and
>> > publish a security update for
24 matches
Mail list logo
