Re: Editor extensions to help editing debian/* files?

[Otto Kekäläinen]

Hi!

> Thats beginning to look like the history of check-all-the-things.

Yeah, I remember looking into cats some years back as a place to learn
what commands exist. Similarly I also occasionally browse
https://pre-commit.com/hooks.html.
The challenge with having all possible checkers is that they create a
lot of noise and managing the false positives end up being a lot of
work. Not suitable for daily use, but I will probably use cats for
"annual checkups" on stuff I maintain.

It would be nice though if the version in Debian was newer :)

Since https://tracker.debian.org/pkg/check-all-the-things lacks a
working git and homepage link, you guys should probably do a new
upload to Debian.
By the way, I submitted some small fixes at
https://github.com/collab-qa/check-all-the-things/pulls.

Bug#1061541: ITP: ruby-redis-client -- redis-client is a simple, low-level, client for Redis 6+.

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: ruby-redis-client
  Version : 0.19.1
  Upstream Contact: jean.bouss...@gmail.com
* URL : https://github.com/redis-rb/redis-client
* License : Expat
  Programming Lang: Ruby
  Description : redis-client is a simple, low-level, client for Redis 6+.

 Contrary to the redis gem, redis-client doesn't try to map all Redis commands
 to Ruby constructs, it merely is a thin wrapper on top of the RESP3 protocol.

 This package is a dependency of gitlab. This package will be maintained by
 Debian ruby team.

Processed: closing 1061518

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 1061518
Bug #1061518 {Done: Salvatore Bonaccorso } [general] (no 
subject)
Bug 1061518 is already marked as done; not doing anything.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1061518: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061518
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: icc-profiles_2.2_source.changes REJECTED

[Jonas Smedegaard]

Quoting Jeremy Bícha (2024-01-25 22:05:27)
> On Wed, Jan 24, 2024 at 9:48 PM Jonas Smedegaard  wrote:
> > For the record I have not heard from ftpmasters on this issues, and I
> > know only what is in this public mailinglist thread.
> >
> > Obviously I would be happy to be able to maintain the package that I am
> > listed as maintainer of.  And if that for some reason is unreasonable of
> > me to expect then I would appreciate an explanation why.
> 
> I found https://bugs.debian.org/1021999 which suggests that DSA is
> responsible for maintaining the version of lintian used for the upload
> queue. Do you want to contact them about our request for an upgrade?

I would prefer not to do it.  Please go ahead if you are up for it.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Philipp Kern]

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 promise.  Some aspects of making 
this

work will doubtless be *annoying*, but it doesn't seem outside of our
capabilities as a project.


One worry I'd have is that we have - in the past - been very 
conservative in what we rebuilt. We have not rebuilt the archive 
pre-release either (maybe we should!). So you are suddenly rebuilding 
binaries with a new toolchain and updated inputs - and while it's easy 
to review source diffs, there are always some unknowns what is happening 
to the binary as a result. From a(n ex) release perspective that would 
be my main worry.


I agree that the rebuilds themselves are a matter of programming, 
assuming they succeed and you don't need to do them in stages to resolve 
dependencies. Presumably we'd then need a pipeline to publish partial 
security updates as the leaves of the tree complete (or enough of a 
heads-up). If you have stages because intermediate builds incorporate 
bits of other packages and re-export them into build environments 
(unlikely?) or if you need to shepherd a lot of failed builds and try to 
debug what happened, then it becomes a lot more toilsome and 
labor-intensive.


Kind regards
Philipp Kern

Re: icc-profiles_2.2_source.changes REJECTED

[Jeremy Bícha]

On Wed, Jan 24, 2024 at 9:48 PM Jonas Smedegaard  wrote:
> For the record I have not heard from ftpmasters on this issues, and I
> know only what is in this public mailinglist thread.
>
> Obviously I would be happy to be able to maintain the package that I am
> listed as maintainer of.  And if that for some reason is unreasonable of
> me to expect then I would appreciate an explanation why.

I found https://bugs.debian.org/1021999 which suggests that DSA is
responsible for maintaining the version of lintian used for the upload
queue. Do you want to contact them about our request for an upgrade?

Thank you,
Jeremy Bícha

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Fabian Grünbichler]

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 of all packages that Build-Depends on X and
> >> > publish a security update for all those packages.
> ...
> > I realized that there is one problem with my approach: consider if
> > package A was built via Build-Depends package B of version X and that
> > later package B is upgraded to X+1 in Debian.  Then if a security
> > problem happens in B we need to rebuild A. It may be that package A no
> > longer builds due to some incompatibility between version X and X+1 of
> > B.  This would not be noticed until a full rebuild of an archive is
> > done, or when the security teams wants to rebuild the transitive
> > closure of the Build-Depends graph for a package.
> 
> 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:
> 
>   To fix a security problem in package X, which is used during build
>   (through statical linking, vendoring, or some other mechanism) to
>   build package A, B, C, ... you need to rebuild all packages that
>   Build-Depends on X (lets call this step 1) and all packages that
>   Build-Depends on any of the packages that will be rebuilt during step
>   1.  This rebuild process is iterated until no more packages remains to
>   be rebuild, and all packages have been rebuilt using newly rebuild
>   packages.  If there are cyclical dependencies (which unfortunately are
>   common), you have to loop until all packages have been rebuilt with a
>   clean dependency chain, and detect the loop and stop rebuilding.  If
>   there are FTBFS errors during the rebuilds, this will have to be
>   patched too.
> 
> 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
> publish in an advisory) by either of:
> 
> 1) using information from Built-Using: (which was not designed for
>this purpose, so this is fragile) or *.buildinfo.
> 
> 2) by dropping all 'Architecture: all' packages that does not embedd
>the buggy code.
> 
> The last optimization 2) would reduce the number of Go packages to
> publish significantly, as it would drop most golang-*-dev packages.  I
> think this actually makes this process feasible in practice, as there
> are relatively few binary packages written in Go.
> 
> This method applies to non-Go/Rust too, if there are such security
> problems and reverse build chains.
> 
> I think all of this (except maybe the optimization 2) which requires
> code comparisons) can be automated in a GitLab pipeline for higher
> confidence of the result.

Here's some rough thoughts and numbers for the (packaged) Rust
ecosystem..

Currently in unstable we have ~100 packages shipping binaries
written in Rust that are packaged using the "stock" packaging schema
(that's debcargo/debcargo-conf + dh-cargo + our cargo wrapper) or Jonas'
forked one (which use a slightly different, but mostly compatible
approach), which means dh-cargo-built-using is called and encodes the
static linking information in the binary package in
X-Cargo-Built-Using[0].

Let's add another 50[1] that are using Rust in some fashion and thus
(potentially) contain statically linked Rust code from other source
packages, which are for whatever reason currently not emitting this
information - some examples: src:cargo, src:rustc - these both vendor
their deps and need special handling anyhow, firefox and soon chromium
(similar AFAIK), but also more relevant, python3-cryptography and
friends, or parts of Gnome that are newly or re-written in Rust (these
could and should emit the information, but currently don't).

These are the only packages (besides the librust-foo-dev package
triggering a rebuild) that need a rebuild right now if a security fix
needs to be deployed. But thankfully we don't need to rebuild 1xx
Rust-using packages whenever any crate has a security fix, we only need
to do so if they transitively build-depend on the vulnerable (now fixed)
package/crate. This in effect also means that (for simple cases where
the vulnerability is not spread across multiple crates) we can rebuild
the vulnerable (lib) crate first, and then schedule independent rebuilds
of all binary-shipping packages that statically link it. I attached a
list doing a rough mapping of source package to number of such packages
needing a rebuild if the source package in question gets a security fix.
In my experience (both packaging Rust things in Debian, bu

Re: Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)

[Fabian Grünbichler]

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
> > >> 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 linking wiki page has some references about this.
> > >
> > > https://wiki.debian.org/StaticLinking
> >
> > This reminded me that I'm not even sure that I fully understand what
> > Rust's remaining technical obstacles to achieving dynamic linking (at
> > least within Debian) are. I'm ignoring the potential cultural or
> > political issues that have been alluded to by others. My understanding –
> > and please do correct me! – has been that three components are missing:
> >
> > (1) A stable ABI.
> <...>
> > From Debian's perspective, is really (1) all that important given that a
> > stable release only has to deal with a specific version of the compiler?
> > Could we not live with every new version of *just* rustc in sid
> > introducing a transition with a rebuild of every Rust package?
> 
> A security bug in the standard library would require rebuilding and
> shipping the universe, so yeah I'm pretty sure it's quite fundamental.

it would also be pretty much untenable for unstable/testing:
- rustc releases every 6 weeks
- rustc release N requires N or N-1 to build
- we frequently need to multiple rustc uploads for a single version to
  iron out arch-related issues (some of which only show up when building
  particular crates)
- we have > 2k source package in the rust- namespace alone

keeping rustc somewhat current is already a big effort..


signature.asc
Description: PGP signature

Re: Processed: closing 1061512

[Jérémy Lal]

I always wondered if there was a reason to allow unverified BTS access ?

Le jeu. 25 janv. 2024 à 21:27, Debian Bug Tracking System <
ow...@bugs.debian.org> a écrit :

> Processing commands for cont...@bugs.debian.org:
>
> > close 1061512
> Bug #1061512 [general] 4
> Marked Bug as done
> > thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
> --
> 1061512: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061512
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>

Processed: closing 1061512

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 1061512
Bug #1061512 [general] 4
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1061512: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061512
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: closing 1061518

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 1061518
Bug #1061518 [general] (no subject)
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1061518: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061518
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1061518: (no subject)

[other]

Package: general
Severity: serious
X-Debbugs-Cc: a...@a.com, h...@test.com

Bug#1061513: RFP: xwayland-run -- xwayland-run contains a set of small utilities revolving around running Xwayland

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net, debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: xwayland-run
  Version : 0.0.2
  Upstream Contact: Oliver Fourdan
* URL : https://gitlab.freedesktop.org/ofourdan/xwayland-run
* License : MIT
  Programming Lang: Python
  Description : xwayland-run contains a set of small utilities revolving 
around running Xwayland

The source package contains the following utilities:

xwayland-run, to spawn an X11 client within its own dedicated Xwayland rootful 
instance,
wlheadless-run to run a Wayland client on a set of supported Wayland  headless 
compositors,
and xwfb-run, a combination of the two other tools above to be used as a direct 
replacement for xvfb-run specifically.

CC'ing d-devel because I believe some packages would need this
functionality.

best,

werdahias



-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWytJIVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR11E8P/3DzGpDKBe2mrlknYb8qwmu6fcpL
HaOGXjdwFP1y7yPFE0cPkETHPPbqpVUqka+xvJb+iuEDm7Fsnu9J6Lq0+HbVNMiA
5YkBSscTgFjzFLQODaVLGd5SHhmfriU0t/Av9gxtn+eC7gF6t1z9RnvAZG3+F7nm
Paw69o18UTKmrHYDdLns1idp3KJImqxZg2gWhGvOS4ea5/LexDXDOM5wSUWbi1SU
ubJxZ2/n7Qu5dhJjM3n6DFtsS9BKrNxqQSpCTPXyxDMaxkIS+EqU4X1qxzjGF+xg
BbYyG6nlLypzKHRwYcKzO4gNuuS54fVBhz/2TDpAQYnu9fyBAU6OKzFXShCNwgjJ
tZMFuZYQuWTjR7K93Owfsw29u0tGRPxHrN0sxoTI06msFnUK6VIwxEs8U0JrfVWL
/xCX+GbMxz3Vhl/5a+3Dlm5FaobGnVDGlNs3fPWhqbc2yzDcvH5TUofiu8gMRQJG
uU3MF882TnJ91yc0UtB/3f5Fh680hH+/YMxbNE0U2+1soq8lviyBxBnk5Jqhmn1D
jKpQ1M/vDlJuKbFC9VGqakkR07PtaCcGf4sG8m2j1Zb8E7MKiYNs2tYIW2i07ZCp
F6SLCkIrQIN08LRKHNhm8Nd8RlwON/rgFondRhkU1mKR7Qknp9J07boi+0chRYL7
Ozl4x3UNZUaG0kYx
=t+az
-END PGP SIGNATURE-

Bug#1061512: 4

[other]

Package: general
Severity: important
X-Debbugs-Cc: h...@test.com

Re: Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)

[Luca Boccassi]

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 stable ABI/dynamic linking problem.
> >
> > IIRC that has been worked on for some years now, and IIRC
> > the static linking wiki page has some references about this.
> >
> > https://wiki.debian.org/StaticLinking
>
> This reminded me that I'm not even sure that I fully understand what
> Rust's remaining technical obstacles to achieving dynamic linking (at
> least within Debian) are. I'm ignoring the potential cultural or
> political issues that have been alluded to by others. My understanding –
> and please do correct me! – has been that three components are missing:
>
> (1) A stable ABI.
<...>
> From Debian's perspective, is really (1) all that important given that a
> stable release only has to deal with a specific version of the compiler?
> Could we not live with every new version of *just* rustc in sid
> introducing a transition with a rebuild of every Rust package?

A security bug in the standard library would require rebuilding and
shipping the universe, so yeah I'm pretty sure it's quite fundamental.

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Luca Boccassi]

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 think of this problem as purely a Go/Rust
> > problem.  The parallel argument that we should not support coreutils,
> > sed, tar, gzip etc because they included vendored copies of gnulib code
> > is not reasonable.
>
> Since there are now a bunch of messages on this thread of people grumbling
> about Rust and Go and semi-proposing not even trying to package that
> software (and presumably removing python3-cryptography and everything that
> depends on it? I'm not sure where people think this argument is going), I
> wanted to counterbalance that by saying I completely agree with Simon's
> exploration here.
>
> 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 promise.  Some aspects of making this
> work will doubtless be *annoying*, but it doesn't seem outside of our
> capabilities as a project.

Well, CPu cycles and metadata are not quite the whole story though. It
also takes a huge amount of extra engineering effort, both one-time to
completely rearchitect and reimplement the build and release
infrastructures to deal with this at scale, and ongoing to maintain
the additional complexities for the rest of the project's life. As you
well know, developers time is by far the scarcest resource of them
all.
Also, it means downloading and installing GBs of packages on every
security update, instead of a few KBs, for every user. While not as
bad as the resource issue, it's still not great.

Finally, as an opinion, quite frankly, it's not a very good design.
You can already run a distribution that does static linking for
everything and requires rebuilding the whole universe and then some
every time there's a one character change anywhere - take Yocto and
configure it to use Musl. Having used it for a long time now, it's
_really_ not good and I wouldn't recommend it to anybody. Matter of
taste of course.

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Russ Allbery]

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 argument that we should not support coreutils,
> sed, tar, gzip etc because they included vendored copies of gnulib code
> is not reasonable.

Since there are now a bunch of messages on this thread of people grumbling
about Rust and Go and semi-proposing not even trying to package that
software (and presumably removing python3-cryptography and everything that
depends on it? I'm not sure where people think this argument is going), I
wanted to counterbalance that by saying I completely agree with Simon's
exploration here.

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 promise.  Some aspects of making this
work will doubtless be *annoying*, but it doesn't seem outside of our
capabilities as a project.

Dealing with older versions is of course much more of a problem,
particularly if upstream is not backporting security fixes, but this is a
problem is inherent in having stable releases, that upstreams have been
grumbly about long before either Rust or Go even existed, and that we have
nonetheless dealt with throughout the whole history of Debian.  There is
no one-size-fits-all solution, but we have historically managed to muddle
through in a mostly acceptable way.

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

Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)

[Gard Spreemann]

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 for some years now, and IIRC
> the static linking wiki page has some references about this.
>
> https://wiki.debian.org/StaticLinking

This reminded me that I'm not even sure that I fully understand what
Rust's remaining technical obstacles to achieving dynamic linking (at
least within Debian) are. I'm ignoring the potential cultural or
political issues that have been alluded to by others. My understanding –
and please do correct me! – has been that three components are missing:

(1) A stable ABI.

(2) A way of dealing with generic types/functions across dynamic linking
boundaries.

(3) A way of dealing with macros across dynamic linking boundaries.

From Debian's perspective, is really (1) all that important given that a
stable release only has to deal with a specific version of the compiler?
Could we not live with every new version of *just* rustc in sid
introducing a transition with a rebuild of every Rust package?

As for (2): Since Debian has the privilege of having a complete overview
of the "closed system" of all Rust packages that we need to consider,
could we not conceivably make a pass across all Rust packages in the
entire archive and record every concrete version of every generic
type/function ever used? Then when a particular library package is
built, we would force the monomorphization of all the relevant
types/functions in that shared library's public interface. This would
require tooling support from upstream to force generation of
monomorphized versions of types/functions when building each shared
library, but that in itself does not seem impossible. (As a curious
effect, the introduction of a new package may then trigger the need to
rebuild some of its own dependencies due to new monomorphic versions of
functions being needed that had not been seen in the archive before.)

Similarly, for (3), could we expand every macro in every library as
needed by every depending package in the archive?


Just trying to get a handle on how far we are from a solution of sorts,
apologies for any stupid questions.


 Best,
 Gard



signature.asc
Description: PGP signature

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Marco d'Itri]

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 new' to
> define a stable ABI. That was fair enough for a while, but it's
> getting to be quite a thin excuse at this point. I think the real
The problem here is that many of these upstream developers actually see 
this as a feature: they are happy to not have "old versions" of their 
software shipped by distributions, because this way they can tell users 
to just download the latest pre-built binaries from github or an 
appimage and not care about supporting older releases.

And while this somehow often works for stand-alone desktop or web
applications, it is hell for daemons or other system services which need 
integration with the OS.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Paul Wise]

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 linking wiki page has some references about this.

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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