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 Wed, Jan 24, 2024 at 11:40:20PM +, Wookey wrote:
> If it only done for security issues, rather than routinely, then that
> shouldn't be that much extra load (does anyone have any idea how much
> extra building we are talking about? Is it trivial, or huge?)
If we do those rebuilds in stable
On 2024-01-16 10:59 +0100, Simon Josefsson wrote:
> 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
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
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
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 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
> >
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
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
Adam Borowski writes:
> On Mon, Jan 15, 2024 at 10:17:17AM +0100, Bastian Blank wrote:
>> 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
On Mon, Jan 15, 2024 at 10:17:17AM +0100, Bastian Blank wrote:
> 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
El 16/01/24 a las 17:43, Simon Josefsson escribió:
> Bastian Blank writes:
>
> > On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote:
> >> Rebuilding a bit more than what is strictly needed sounds fine as a
> >> first solution to me.
> >
> > Building maybe. But how do you want to
> "Simon" == Simon Josefsson writes:
Simon> Right, these are slightly different technical problems, but
Simon> as far as the brief discussion in the release notes --
Simon>
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking
Bastian Blank writes:
> On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote:
>> Rebuilding a bit more than what is strictly needed sounds fine as a
>> first solution to me.
>
> Building maybe. But how do you want to publish them? The security
> archive is not made to handle that.
On 1/16/24 17:20, Simon Josefsson wrote:
it seems that many people think that "Built-Using" can be used to
express static linking (including yours truly, even though i *know*
that it is meant for license compliance only).
which makes me wonder: probably we should have an additional field
that
"IOhannes m zmölnig (Debian GNU|Linux)" writes:
> On 1/16/24 13:56, Jérémy Lal wrote:
>>>
>>> As Built-Using is for license compliance only, no?
>>>
>>> See
>>>
>>> https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
>>
On Tue, Jan 16, 2024 at 04:44:14PM +0100, IOhannes m zmölnig (Debian GNU|Linux)
wrote:
> On 1/16/24 13:56, Jérémy Lal wrote:
> > >
> > > As Built-Using is for license compliance only, no?
> > >
> > > See
> > >
> > >
On 1/16/24 13:56, Jérémy Lal wrote:
As Built-Using is for license compliance only, no?
See
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
Indeed, thanks for the link.
it seems that many people think that
Le mar. 16 janv. 2024 à 13:09, Bastian Blank a écrit :
> On Tue, Jan 16, 2024 at 11:22:48AM +0100, Jérémy Lal wrote:
> > I naively believed that golang-* packages expressed those dependencies
> with
> > "Built-Using".
>
> As Built-Using is for license compliance only, no?
>
> See
>
>
On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote:
> Rebuilding a bit more than what is strictly needed sounds fine as a
> first solution to me.
Building maybe. But how do you want to publish them? The security
archive is not made to handle that.
> My naive approach on how to fix
On Tue, Jan 16, 2024 at 11:22:48AM +0100, Jérémy Lal wrote:
> I naively believed that golang-* packages expressed those dependencies with
> "Built-Using".
As Built-Using is for license compliance only, no?
See
tis 2024-01-16 klockan 11:22 +0100 skrev Jérémy Lal:
>
>
> Le mar. 16 janv. 2024 à 11:00, Simon Josefsson
> a écrit :
> > Paul Wise writes:
> >
> > > On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote:
> > >
> > > > I asked for practical solutions, not theoretical ones. We
> > > > don't
Le mar. 16 janv. 2024 à 11:00, Simon Josefsson a
écrit :
> Paul Wise writes:
>
> > 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.
> >
> >
Paul Wise writes:
> 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:
>
>
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
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
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
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.
> The problem with dependencies are more obvious for Go/Rust code but I
> think we always have had that problem anyway.
Another
Bastian Blank writes:
> Hi Simon
>
> On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote:
>> As an analogy, consider the ./configure scripts that is generated by
>> autoconf during build of many packages. The script typically generate
>> code that is put into config.h that is used
Hi Simon
On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote:
> As an analogy, consider the ./configure scripts that is generated by
> autoconf during build of many packages. The script typically generate
> code that is put into config.h that is used (statically) during
> compilation
On Sun, 2024-01-14 at 10:47 +0100, Simon Josefsson wrote:
> The more I think about it, I think it seems unfair to categorize this
> as a Go/Rust problem.
The point is that it should be possible all packages in Debian without
dependencies which are outside of Debian.
The same problem exists with
On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote:
> Stephan Verbücheln writes:
>
> > On Sat, 30 Dec 2023 12:47:48 + Colin Watson
> > wrote:
> >> I also feel that something security-critical like this that's
> >> labelled by upstream as "still experimental" probably shouldn't
Stephan Verbücheln writes:
> On Sat, 30 Dec 2023 12:47:48 + Colin Watson
> wrote:
>> I also feel that something security-critical like this that's
>> labelled by upstream as "still experimental" probably shouldn't
>> be in a Debian release.
>
> It is written in Go. The problem of Go library
34 matches
Mail list logo
