Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Colin Watson]

On Tue, Apr 02, 2024 at 03:27:30AM +0200, Christoph Anton Mitterer wrote:
> Do you think it will be possible to have still only one `ssh`, `scp`,
> etc. command and that will just use extra GSSAPI stuff if installed and
> needed by a certain connection?

It would be technically possible to retain the client parts of the
GSS-API key exchange patch in the default variant.  It would require the
build to be separated into multiple passes, since that patch touches a
number of files shared by the client and the server.

Rather than trying to construct this, though, it would be much simpler
and I think safer to just have a separate openssh-client-gsskeyex
package.  Like today's openssh-client, it would be usable both with and
without GSS-API key exchange.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: xz backdoor

[Francesco P. Lovergine]

On Sun, Mar 31, 2024 at 12:39:55PM +0200, Johannes Schauer Marin Rodrigues 
wrote:

In summary: would running unstable instead of bookworm let me find more bugs
than running bookworm with unstable chroots? For my specific work: yes,
absolutely.  Am I upgrading from bookworm to unstable or at least testing?
Absolutely not. I just don't have the amount of free-time this would require of
me.  Just performing the 12-13 bisection steps to find the offending kernel
commit which makes my system lock up would easily require a day of free time
from me.  I'm afraid I do not have this luxury. Not even remotely close!



+1 


I run stably and alternatively 4-6 different personal boxes during the week, all
with stable. Dedicating time to debugging silly egg-and-chicken breakages due 
to sid
life cycle (anyone nominated 64t saga?) is out of discussion. I did
that years ago, when I had more time an less personal boxes to run.


So I'll continue to not dogfood as hard as I could and run as much from
bookworm as I can. Would it make me a better contributor if I ran unstable?
Certainly! But this thing is just a hobby of mine and I can only allot that
much time to do risky experiments with my only computer. I guess others are in
the same boat?


I would also add that even stable/oldstable needs care, and I need to support
multiple users to have a decent workflow on them. Our main network runs
about a dozen of general purpose stable servers/VMs and that's more than enough.

That said I still run a single sid boxes (no GPG/essential keys there)
and I would add that some bugs can be seen only at stable upgrade time
or during the testing life-cycle, not when one runs sid all time. 


A lot of issues can be found only by running accurate tests on fresh
boxes, not via sid daily use, which is only a part of the whole story.

--
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Re: xz backdoor

[Francesco P. Lovergine]

On Fri, Mar 29, 2024 at 09:09:45PM +0100, Sirius wrote:

Hi there,

This is quite actively discussed on Fedora lists.
https://www.openwall.com/lists/oss-security/2024/
https://www.openwall.com/lists/oss-security/2024/03/29/4

Worth taking a look if action need to be taken on Debian.



Speaking about that, I'm a simple guy: how can anyone trust
sources signed by an unsigned-gnupg-key committer (I mean both the
actors of this tragically ridicolous drama)? 
In 2024. Really?

Even the unperfect web-of-trust is better than nothing at all.

--
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Marco d'Itri]

On Apr 02, Colin Watson  wrote:

> At the time, denyhosts was popular, but it was removed from Debian
> several years ago.  I remember that, when I dealt with that on my own
> systems, fail2ban seemed like the obvious replacement, and my impression
> is that it's pretty widely used nowadays; it's very pluggable but it
> normally works by adding firewall rules.  Are there any similar popular
> systems left that rely on editing /etc/hosts.deny?
Yes, people. I object to removing TCP wrappers support since the patch 
is tiny and it supports use cases like DNS-based ACLs which cannot be 
supported by L3 firewalls.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Tue, Apr 02, 2024 at 11:49:50AM +0200, Francesco P. Lovergine wrote:
> Speaking about that, I'm a simple guy: how can anyone trust
> sources signed by an unsigned-gnupg-key committer (I mean both the
> actors of this tragically ridicolous drama)? In 2024. Really?
As opposed to sources not signed by any key at all?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Christian Göttsche]

On Tue, 2 Apr 2024 at 02:30, Colin Watson  wrote:
>
> [I've CCed openssh-unix-dev for awareness, but set Mail-Followup-To to
> just debian-devel and debian-ssh to avoid potentially spamming them with
> a long discussion.  If you choose to override this then that's your
> call, but please be mindful of upstream's time.]
>
> Following the xz-utils backdoor, I'm reconsidering some choices in
> Debian's OpenSSH packaging.  Please note that significant rearchitecture
> of the upstream code is out of scope for the Debian packaging, so I'm
> going to disregard comments of the form "maybe there should be a module
> loader so all these things can just be plug-ins" or other such blue-sky
> things; from my point of view this is just about configuring things a
> bit more wisely within more or less our current constraints.
>
>
> libsystemd
> ==
>
> This is the obvious thing on everyone's mind right now.  At the time I
> merged that patch, "not NIHing code that's in a perfectly good library"
> seemed like a reasonable trade-off, but we do seem to have ended up on
> the wrong side of history on this one.  There's work in progress to land
> readiness protocol notification upstream without libsystemd (thanks
> Damien and Luca!), and I expect to cherry-pick this into Debian once
> it's agreed, so we'll get rid of that linkage and reduce our patch load
> a bit.
>
> We also have a patch from Ubuntu to support the systemd socket
> activation protocol.  I've rewritten this to avoid using libsystemd, and
> I'll submit it upstream once the readiness notification work is sorted
> out.  But it's not particularly invasive once the libsystemd linkage is
> removed, so it's not the end of the world if this ends up staying in our
> patch queue.
>
>
> GSS-API key exchange
> 
>
> Way back in 2005, I merged the GSS-API key exchange patch into Debian's
> main openssh package (https://bugs.debian.org/275472).  At the time it
> seemed like a sensible overall reduction in maintenance burden (if I
> remember correctly, the openssh-krb5 package often ended up lagging a
> fair bit behind openssh).  While the patch is fairly large, it hasn't
> generally been too hard to forward-port to newer versions of OpenSSH,
> and Fedora carries it too so there's some sharing of work.
>
> However, OpenSSH upstream has long rejected it, mainly on the basis that
> they don't like adding new pre-authentication attack surface, and this
> week seems like a good one to reconsider what patches we're shipping by
> default.  gssapi.patch is the largest patch in our openssh package by an
> order of magnitude, and easily the most intrusive in terms of complexity
> and exposure, so I've somewhat regretted my choice to merge it a few
> times over the years.
>
> All the same, I'm aware that some people now depend on having this
> facility in Debian's main openssh package: I get enough occasional bug
> reports to convince me that it's still in use.  So, if I decide to split
> it back out, I'd want to arrange for a somewhat graceful transition.
> We've had it for nearly 20 years now, so we can take the time to do a
> proper job that at least tries not to leave users in the lurch.
>
> How does this rough plan sound?
>
>  * for Debian trixie (current testing):
>
>* add dependency-only packages called something like
>  openssh-client-gsskex and openssh-server-gsskex, depending on their
>  non-gsskex alternatives
>* add NEWS.Debian entry saying that people need to install these
>  packages if they want to retain GSS-API key exchange support
>* add release note saying the same
>
>  * for Debian trixie+1 (or maybe after the next Ubuntu LTS, depending on
>exact timings):
>
>* add separate openssh-gsskex source package, carrying gssapi.patch
>  in addition to whatever's in openssh, and whose binary packages
>  Conflicts/Replaces/Provides the corresponding ones from openssh
>* add some kind of regular CI to warn about openssh-gsskex being out
>  of date relative to openssh
>* drop gssapi.patch from openssh, except for small patches to
>  configuration file handling to accept the relevant options with
>  some kind of informative warning (compare
>  https://bugs.debian.org/152657)
>
> I guess we should decide whether the separate packages are to be needed
> for GSS-API authentication as well as key exchange, because that affects
> the choice of dependency-only package names in trixie.  If we only split
> out gssapi.patch (for key exchange; sorry about the slightly misleading
> name) but kept --with-kerberos5 (which also controls authentication),
> then we'd significantly reduce our patch load but not sshd's linkage.
>
> I've seen the suggestion of using libgssglue here
> (https://fosstodon.org/@jas/112194876950058188).  That might be a good
> idea and I have no particular objection to it, though I also don't know
> much about it and it would probably be better if an expert did the work.
> Perhaps

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Colin Watson]

On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote:
> On Apr 02, Colin Watson  wrote:
> > At the time, denyhosts was popular, but it was removed from Debian
> > several years ago.  I remember that, when I dealt with that on my own
> > systems, fail2ban seemed like the obvious replacement, and my impression
> > is that it's pretty widely used nowadays; it's very pluggable but it
> > normally works by adding firewall rules.  Are there any similar popular
> > systems left that rely on editing /etc/hosts.deny?
> 
> Yes, people. I object to removing TCP wrappers support since the patch 
> is tiny and it supports use cases like DNS-based ACLs which cannot be 
> supported by L3 firewalls.

It's not about the size of the patch.

You could use a drop-in unit to wrap sshd in tcpd, as suggested by the
Fedora wiki page?  This would avoid exposing sshd's process space to
libwrap and all the stuff it links to by default.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Marco d'Itri]

On Apr 02, Colin Watson  wrote:

> You could use a drop-in unit to wrap sshd in tcpd, as suggested by the
> Fedora wiki page?  This would avoid exposing sshd's process space to
> libwrap and all the stuff it links to by default.
This would require to switch to socket activation of sshd, which is not 
the default for good reasons.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Colin Watson]

On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote:
> Yes, people. I object to removing TCP wrappers support since the patch 
> is tiny and it supports use cases like DNS-based ACLs which cannot be 
> supported by L3 firewalls.

I suspect OpenSSH upstream would also want me to point out that
DNS-based ACLs are supported by Match blocks without needing a separate
library.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Mot de passe

[Ghislain Pierrat]

Bonjour , 
En tant qu’utilisateur de produit APPLE , j’utilise le gestionnaire de mot de 
passe TROUSSEAU
Je me connecte épisodiquement sur un site de données biologiques de santé pour 
lequel un mot de passe m’a été fourni . Ce mot de passe est déclaré faible par 
le gestionnaire ; en tentant de le changer à l’aide du  gestionnaire je suis 
aiguillé sur une page de votre site sans pouvoir changer ce mot de passe 
Est il possible de le faire et comment ?
Merci de votre réponse

G P

Re: Mot de passe

[Yadd]

On 4/2/24 15:03, Ghislain Pierrat wrote:

Bonjour ,
En tant qu’utilisateur de produit APPLE , j’utilise le gestionnaire de mot de 
passe TROUSSEAU
Je me connecte épisodiquement sur un site de données biologiques de santé pour 
lequel un mot de passe m’a été fourni . Ce mot de passe est déclaré faible par 
le gestionnaire ; en tentant de le changer à l’aide du  gestionnaire je suis 
aiguillé sur une page de votre site sans pouvoir changer ce mot de passe
Est il possible de le faire et comment ?
Merci de votre réponse

G P


Sorry for fellow Debian Developers, I'll answer in French.


Bonjour,

ceci est une liste de diffusion en anglais et très éloignée de votre sujet.
Le système Trousseau est un gestionnaire de mots-de-passe d'Apple et ici 
vous écrivez à une liste rassemblant les développeurs du système 
d'exploitation Debian.
Je ne comprends pas du tout comment vous avez été ré-aiguillé ici mais 
il est fort probable que personne ici ne puisse vous aider. 
Adressez-vous plutôt à votre support Apple.


Cordialement,

Re: Mot de passe

[Abou Sanou]

Hello
J’ai l’impression que vous vous êtes trompé de canal.
Cet outil a t’il un lien avec Debian ou packages annexes à Debian ??

On Tue 2 Apr 2024 at 13:30, Ghislain Pierrat  wrote:

> Bonjour ,
> En tant qu’utilisateur de produit APPLE , j’utilise le gestionnaire de mot
> de passe TROUSSEAU
> Je me connecte épisodiquement sur un site de données biologiques de santé
> pour lequel un mot de passe m’a été fourni . Ce mot de passe est déclaré
> faible par le gestionnaire ; en tentant de le changer à l’aide du
> gestionnaire je suis aiguillé sur une page de votre site sans pouvoir
> changer ce mot de passe
> Est il possible de le faire et comment ?
> Merci de votre réponse
>
> G P
>

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Marc Haber]

On Tue, 2 Apr 2024 01:30:10 +0100, Colin Watson 
wrote:
>We carry a patch to restore support for TCP wrappers, which was dropped
>in OpenSSH 6.7 (October 2014); see
>https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
>and thread.  That wasn't long before the Debian 8 (jessie) freeze, and
>so I patched it back in "temporarily", but then I dropped the ball on
>organizing a proper transition. 

Please don't drop the mechanism that saved my¹ unstable installations
from being vulnerable to the current xz-based attack. Just having to
dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to
maintain a packet filter.

Greetings
Marc

¹ and probably thousands others
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: xz backdoor

[Emanuele Rocca]

Hi,

On 2024-03-30 10:49, Jonathan Carter wrote:
> Another big question for me is whether I should really still
> package/upload/etc from an unstable machine.

I have been using unstable myself on most of my systems for the past
several years. There are many advantages, including being able to
actually test Debian as many have said in this thread. Case in point,
the xz backdoor has been discovered by a Debian unstable user: it would
have likely been found much later had they used stable instead.

Without trying to be overly dramatic though, I consider the xz incident
as some sort of 9/11 of Linux distros. Everyone knew it could have
happened, but now that it has and we see how relatively easy it was I
think it's time to re-evaluate things. I now do not think anymore that
sid is secure enough for high-profile targets such as DDs. All it takes
is one bad upload, and your systems are immediately compromised. Sure
bad stuff can eventually make it to stable as well, but the longer it
takes the more likely for the malicious change to be spotted.

Other than the time aspect, there's the problem of binary uploads too.
How long would it take to spot a well crafted, malicious binary upload
to sid?

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[RL]

Colin Watson  writes:

> GSS-API key exchange
> 

> However, OpenSSH upstream has long rejected it

> All the same, I'm aware that some people now depend on having this
> facility in Debian's main openssh package


> How does this rough plan sound?
>
>  * for Debian trixie (current testing):
>
>* add dependency-only packages called something like
>  openssh-client-gsskex and openssh-server-gsskex, depending on their
>  non-gsskex alternatives
>* add NEWS.Debian entry saying that people need to install these
>  packages if they want to retain GSS-API key exchange support
>* add release note saying the same

happy to help on release-notes.

Think you've got two audiences:

- people who rely on gss, who may be upgrading over ssh and need to know
  how to avoid being locked out (eg: make sure to install gsskex
  recommended packages before reboot?)

- people who dont use gss, and want to remove it asap: as well as
  removing the gsskex packages would they need to edit sshd_config or
  ssh_config etc -- these can currently contain things like
  'GSSAPIAuthentication no' which would (i assume) stop working (and
  cause sshd to not start) once the gss support is removed(?)

Re: Validating tarballs against git repositories

[Adrian Bunk]

On Mon, Apr 01, 2024 at 11:17:21AM -0400, Theodore Ts'o wrote:
> On Sat, Mar 30, 2024 at 08:44:36AM -0700, Russ Allbery wrote:
>...
> > Yes, perhaps it's time to switch to a different build system, although one
> > of the reasons I've personally been putting this off is that I do a lot of
> > feature probing for library APIs that have changed over time, and I'm not
> > sure how one does that in the non-Autoconf build systems.  Meson's Porting
> > from Autotools [1] page, for example, doesn't seem to address this use
> > case at all.
> 
> The other problem is that many of the other build systems are much
> slower than autoconf/makefile.  (Note: I don't use libtool, because
> it's so d*mn slow.)  Or building the alternate system might require a
> major bootstrapping phase, or requires downloading a JVM, etc.

The main selling point of Meson has been that it is a lot faster
than autotools.

> > Maybe the answer is "you should give up on portability to older systems as
> > the cost of having a cleaner build system," and that's not an entirely
> > unreasonable thing to say, but that's going to be a hard sell for a lot of
> > upstreams that care immensely about this.
> 
> Yeah, that too.  There are still people building e2fsprogs on AIX,
> Solaris, and other legacy Unix systems, and I'd hate to break them, or
> require a lot of pain for people who are building on MacPorts, et. al.
>...

Everything you mention should already be supported by Meson.

>   - Ted

cu
Adrian

Bug#1068245: ITP: iwgtk -- lightweight graphical frontend to iwd

[Mark Hindley]

Package: wnpp
Severity: wishlist
Owner: Mark Hindley 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: iwgtk
  Version : 0.9
  Upstream Contact: Jesse Lentz 
* URL : https://github.com/J-Lentz/iwgtk
* License : GPL3+
  Programming Lang: C
  Description : Lightweight graphical frontend to iwd

iwgtk is a lightweight gtk4 frontend to iwd which provides similar
functionality to that of iwctl.
 
Features include viewing and connecting to available networks, managing known
networks, provisioning new networks via WPS or Wi-Fi Easy Connect and an
indicator (tray) icon displaying connection status and signal strength.

Mark

Re: Validating tarballs against git repositories

[Russ Allbery]

Adrian Bunk  writes:
> On Mon, Apr 01, 2024 at 11:17:21AM -0400, Theodore Ts'o wrote:

>> Yeah, that too.  There are still people building e2fsprogs on AIX,
>> Solaris, and other legacy Unix systems, and I'd hate to break them, or
>> require a lot of pain for people who are building on MacPorts, et. al.
>>...

> Everything you mention should already be supported by Meson.

Meson honestly sounds great, and I personally love the idea of using a
build system whose language is a bit more like Python, since I use that
language professionally anyway.  (It would be nice if it *was* Python
rather than yet another ad hoc language, but I also get why they may want
to restrict it.)

The prospect of converting 25 years of portability code from M4 into a new
language is daunting, however.  For folks new to this ecosystem, what
resources are already available?  Are there large libraries of tests
already out there akin to gnulib and the Autoconf Archive?  Is there a
really good "porting from Autotools" guide for Meson that goes beyond the
very cursory guide in the Meson documentation?

The problem with this sort of migration is that it is an immense amount of
work just to get back to where you started.  I look at the amount of
effort and start thinking things like "well, if I'm going to rewrite a
bunch of things anyway, maybe I should just rewrite the software in Rust
instead."

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

Re: autoreconf --force not forcing (was Re: Validating tarballs against git repositories)

[Adrian Bunk]

On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
>...
> On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
>...
> > This seems like a serious bug in autoreconf, but I've not checked if
> > this has been brought up upstream, and whether they consider it's
> > working as intended. I expect the serial to be used only when not
> > in --force mode though. :/
>...
> We might have to perform a mass rebuild to check if there could be
> fallout out of a true --force behavior change I guess.

Does gnulib upstream support upgrading/downgrading the gnulib m4 files
(like the one used in the xz backdoor) without upgrading/downgrading
the corresponding gnulib C files?

> Thanks,
> Guillem

cu
Adrian

Re: autoreconf --force not forcing (was Re: Validating tarballs against git repositories)

[Colin Watson]

On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
> > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> > > This seems like a serious bug in autoreconf, but I've not checked if
> > > this has been brought up upstream, and whether they consider it's
> > > working as intended. I expect the serial to be used only when not
> > > in --force mode though. :/
> >...
> > We might have to perform a mass rebuild to check if there could be
> > fallout out of a true --force behavior change I guess.
> 
> Does gnulib upstream support upgrading/downgrading the gnulib m4 files
> (like the one used in the xz backdoor) without upgrading/downgrading
> the corresponding gnulib C files?

Yes, although it takes a bit of effort.  You can use the --local-dir
option of gnulib-tool, which allows overriding individual Gnulib files
or modules or applying patches to Gnulib files; or you can define a
bootstrap_post_import_hook function in bootstrap.conf and do whatever
you want there.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: autoreconf --force not forcing (was Re: Validating tarballs against git repositories)

[Adrian Bunk]

On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote:
> On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> > On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
> > > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> > > > This seems like a serious bug in autoreconf, but I've not checked if
> > > > this has been brought up upstream, and whether they consider it's
> > > > working as intended. I expect the serial to be used only when not
> > > > in --force mode though. :/
> > >...
> > > We might have to perform a mass rebuild to check if there could be
> > > fallout out of a true --force behavior change I guess.
> > 
> > Does gnulib upstream support upgrading/downgrading the gnulib m4 files
> > (like the one used in the xz backdoor) without upgrading/downgrading
> > the corresponding gnulib C files?
> 
> Yes, although it takes a bit of effort.  You can use the --local-dir
> option of gnulib-tool, which allows overriding individual Gnulib files
> or modules or applying patches to Gnulib files; or you can define a
> bootstrap_post_import_hook function in bootstrap.conf and do whatever
> you want there.

I had the impression that what Guillem has in mind is more towards 
adding dependencies on packages like gnulib and autoconf-archive
to dh-autoreconf, which would then blindly overwrite all m4 files
where a copy (same or older or newer) exists on the build system.

cu
Adrian

Re: Validating tarballs against git repositories

[PICCA Frederic-Emmanuel]

One missing piece for me in order to migrate to meson is the integration 
between flymake and the autotools.

https://www.emacswiki.org/emacs/FlyMake#h5o-7

Re: Firmwares (was Re: Bits from the DPL)

[Gunnar Wolf]

Andrey Rakhmatullin dijo [Mon, Apr 01, 2024 at 10:41:45PM +0500]:
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often not up to date).

There are many firmware packages that don't come from the linux
sources. i.e., I maintain raspi-firmware, the blob needed to boot the
Raspberry Pi family of computers.

And not even following upstream is always enough --- as a data point,
up until a year ago, the Raspberry Pi foundation used to regularly tag
releases in their Github repo¹, but they no longer do that. Of course,
I am not inclined to ship to Debian an unsanctioned what would amount
to just a random snapshot (of course, impossible to review or bugtrack
in any meaningful way) of their blob :-\

¹ https://github.com/raspberrypi/firmware


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Richard Laager]

On 2024-04-02 11:05, Russ Allbery wrote:

Meson honestly sounds great, and I personally love the idea of using a
build system whose language is a bit more like Python, since I use that
language professionally anyway.  (It would be nice if it *was* Python
rather than yet another ad hoc language, but I also get why they may want
to restrict it.)


If Python is what you want, you could use waf, but there is one big 
downside... You have to repack the upstream tarball: 
https://wiki.debian.org/UnpackWaf


--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: autoreconf --force not forcing (was Re: Validating tarballs against git repositories)

[Colin Watson]

On Tue, Apr 02, 2024 at 08:20:31PM +0300, Adrian Bunk wrote:
> On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote:
> > On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> > > Does gnulib upstream support upgrading/downgrading the gnulib m4 files
> > > (like the one used in the xz backdoor) without upgrading/downgrading
> > > the corresponding gnulib C files?
> > 
> > Yes, although it takes a bit of effort.  You can use the --local-dir
> > option of gnulib-tool, which allows overriding individual Gnulib files
> > or modules or applying patches to Gnulib files; or you can define a
> > bootstrap_post_import_hook function in bootstrap.conf and do whatever
> > you want there.
> 
> I had the impression that what Guillem has in mind is more towards 
> adding dependencies on packages like gnulib and autoconf-archive
> to dh-autoreconf, which would then blindly overwrite all m4 files
> where a copy (same or older or newer) exists on the build system.

Oh, I see what you mean now.

IMO it would be a mistake to attempt to do this in such a way that it
upgraded only the m4 files and not the C files.  Changes made to gnulib
modules (which typically consist of some m4, some C, and some metadata)
often touch both m4 and C at once; it seems unwise to try to arbitrarily
split those up.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Firmwares (was Re: Bits from the DPL)

[Didier 'OdyX' Raboud]

Le lundi, 1 avril 2024, 19.41:45 h CEST Andrey Rakhmatullin a écrit :
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often not up to date).

My recollection, after getting some MRs merged in the firmware-nonfree package 
last cycle (oh, a year gone already), is that it's a mix of:

* the maintainers in position to review, then merge the proposed changes are 
few, and have plenty on their hands;

* firmware packages seem to have lower priority during the development cycle, 
in favour of larger updated shortly-before (or during) the freeze;

* upstream and Debian (maintainers) are not in complete agreement on what can, 
or should be shipped in packages; from README.source:
> Also, some of its contents are not clearly redistributable, and some are
> obsolete for Debian's purposes.

So almost every file addition needs a careful `git log` review to check for 
origin, updates, reasoning, version strings, etc. Unless there's tooling I 
have not found; it's tedious, error-prone (and not very interesting) work 
(although quite arguably necessary).

* packaging is very smart, but peculiar (or at least, quite different to what 
I had been used to before I touched it). Despite good documentation, it's 
quite a steep intro for newcomers.

All-in-all, I think it's an all-too-classical case of "we don't have enough 
humanpower for the job we set out to do". Add a team of motivated individuals 
to gain the confidence of the existing "already-plenty-on-their-plates 
maintainers", to then maintain the package on their own. Oh, wait…

-- 
OdyX

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

Bug#1068261: ITP: quickflux -- Flux implementation for QML

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: quickflux
  Version : 1.0.3+git
  Upstream Contact: Ben Lau 
* URL : https://github.com/benlau/quickflux
* License : Apache-2.0
  Programming Lang: C++
  Description : Flux implementation for QML

 An implementation of Flux Application Architecture Framework from
 Facebook. It turns your QML application into a more modern and
 structured way.
 .
 This QML module is needed by several Lomiri apps such as telePORTS
 and Dekko.
 .
 This package will be maintained by the Debian UBports Packaging team.

Re: xz backdoor

[Pierre-Elliott Bécue]

Iustin Pop  wrote on 01/04/2024 at 12:29:59+0200:

> On 2024-03-31 22:23:10, Arto Jantunen wrote:
>> Didier 'OdyX' Raboud  writes:
>> 
>> > Le dimanche, 31 mars 2024, 14.37:08 h CEST Pierre-Elliott Bécue a écrit :
>> >> I would object against creating a PGP key on the HSM itself. Not having
>> >> the proper control on the key is room for disaster as soon as you lose
>> >> it or it dies.
>> >
>> > For subkeys, isn't that a benefit rather than a disadvantage?
>> >
>> > You lose the key, or it gets destroyed / unusable; good, you get a new 
>> > subkey 
>> > instead of reusing the existing one on a different HSM.
>> 
>> For the authentication and signing subkeys this is indeed true. For the
>> encryption subkey significantly less so (as things encrypted against
>> that key then become impossible to decrypt).
>> 
>> Personally I have generated the signing and authentication subkeys on
>> the HSM itself (and thus at least in theory they cannot leave the HSM),
>> and the encryption subkey I have generated on an airgapped system and
>> stored on the HSM after making a couple of backups.
>
> I am really confused now on how all this works. How can you generate
> parts of a key (i.e. subkeys) on the HSM (well, yubikey), and the other
> parts locally?

If you have a master key on your laptop, when a yubikey is in, while
running gpg --edit-key your_main_key, you can use the "addcardkey" to
create a subkey on the Yubikey directly.

-- 
PEB


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Xiyue Deng]

PICCA Frederic-Emmanuel 
writes:

> One missing piece for me in order to migrate to meson is the integration 
> between flymake and the autotools.
>
> https://www.emacswiki.org/emacs/FlyMake#h5o-7
>

There is an unofficial Meson LSP[1].  Maybe it can be configured with
Eglot or lsp-mode.

-- 
Xiyue Deng

[1] https://github.com/JCWasmx86/mesonlsp

Re: xz backdoor

[Paul R. Tagliamonte]

On Tue, Apr 2, 2024 at 5:12 PM Pierre-Elliott Bécue  wrote:

> If you have a master key on your laptop, when a yubikey is in, while
> running gpg --edit-key your_main_key, you can use the "addcardkey" to
> create a subkey on the Yubikey directly.
>

Yeah, seconded for sure. This is the configuration my Debian key is in --
it has an offline root key, which is stored on an LVM encrypted external
drive, and when I need to use it (new yubikey, or updating expiry), I use
an offline only box to mount the lvm drive, plug in the yubikey, and update
the key, exporting the public key to load into my daily box.

It's worked well, and this has been my workflow for a few years now (since
2019). It's not the easiest workflow (I've let my key expire twice because
I couldn't get the offline box set up and key ceremony done in time) but
it's worked well for me, and I'm especially sensitive about keeping private
key material off my disks where I can. I'd rather eat the cost of the setup
over exposing the project to additional keying material sitting around my
disk.

-- 
:wq

Re: Validating tarballs against git repositories

[Thomas Goirand]

On 4/1/24 00:32, Stefano Rivera wrote:

So... for Python packages using setuptools-scm, we're pushed towards
depending on upstream-created source tarballs (sdists), rather than
upstream git archives, because we don't have the ".git" directory in our
source packages.


Hi Stefano,

Thanks for jumping in this thread, though I'll have to disagree with 
you... with all due respect! :)


As you know, I'm by far the biggest uploader of Python modules in 
Debian, due to the fact I'm maintaining OpenStack. As you may know as 
well, the reason I'm not maintaining all of that inside the Debian 
Python Team, is only because it's forbidden to use an upstream git tag 
workflow in the team, and that I have to use pristine-tar. I very much 
regret this fact, but live with it when I have to package within the 
Debian Python Team.


Anyways, on the 400+ packages that I maintain within the OpenStack team, 
I did come across some upstream using setuptools-scm. To my experience, 
using the:


git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
| xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz

workflow out of an upstream always work, including for those that are 
using setuptools-scm. One simply needs to add the dependency, and 
correctly set, with something like this:


SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -SVersion \
| sed -e 's/^[[:digit:]]*://' \
-e 's/[-].*//' \
-e 's/~/.0/' \
-e 's/+dfsg1//' \
| head -n 1)

Because I'm dealing with the DPT packages as well, I can tell, and I 
insist: the workflow to to work with upstream Git is a way nicer than 
the pristine-tar / gbp import-orig one. The upstream tag workflow 
*ALWAYS* work, and often (even: always, for the case of Python modules) 
contain less pre-built artifacts.


Also, sdists are *not* "upstream-created source tarballs". I consider 
the binary form built for PyPi. Just like we have .debs, PyPi has 
tarballs and wheels, rather than how you describe them.


By the way, am I the only one to think that's so lame to use tarballs in 
so many ways... Isn't this a so ... legacy retro-computing format? :)


Cheers,

Thomas Goirand (zigo)

Re: Validating tarballs against git repositories

[Thomas Goirand]

On 3/30/24 08:02, Gioele Barabucci wrote:
For too many core packages there is an opaque "something happens on the 
Debian maintainer laptop" step that has no place in 2024.



Let's replace this by an opaque "something happens on the Salsa CI".


Cheers,

Thomas Goirand (zigo)

Bug#1068289: ITP: wtmpdb -- Y2038 safe wtmp implementation

[Chris Hofstaedtler]

Package: wnpp
Severity: wishlist
Owner: Chris Hofstaedtler 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: wtmpdb
  Version : 0.11.0
  Upstream Contact: Thorsten Kukuk
* URL : https://github.com/thkukuk/wtmpdb
* License : BSD
  Programming Lang: C
  Description : Y2038 safe wtmp implementation

Replacement implementation of utmp/wtmp/last that is supposed to be
Y2038 safe. Provides PAM module to plug into the existing auth stack.

Git Repo will be at https://salsa.debian.org/debian/wtmpdb 

Re: Validating tarballs against git repositories

[Stefano Rivera]

Hi Thomas (2024.04.02_22:33:47_+)
> Anyways, on the 400+ packages that I maintain within the OpenStack team, I
> did come across some upstream using setuptools-scm. To my experience, using
> the:
> 
> git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
>   | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz
> 
> workflow out of an upstream always work, including for those that are using
> setuptools-scm.

Then you haven't come across any that are using this mechanism to
install data, yet. You're only seeing the version determination.
You will, at some point run into this problem. It's getting more
popular.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Validating tarballs against git repositories

[Russ Allbery]

Stefano Rivera  writes:

> Then you haven't come across any that are using this mechanism to
> install data, yet. You're only seeing the version determination.  You
> will, at some point run into this problem. It's getting more popular.

Yup, we use this mechanism heavily at work, since it avoids having to
separately maintain a MANIFEST.in file.  Anything that's checked in to Git
in the appropriate trees ships with the module.  But this means that you
have to build the module from a Git repository, if you're not using the
artifact uploaded to PyPI (which expands out all the information derived
from Git).

If I correctly remember the failure mode, which I sometimes run into
during local development if I forget to git add new data files, the data
files are just not installed since nothing tells the build system they
should be included with the module.

I think a shallow clone of depth 1 is sufficient, although that's not
sufficient to get the correct version number from Git in all cases.

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

Re: Validating tarballs against git repositories

[Jeremy Stanley]

On 2024-04-03 00:33:47 +0200 (+0200), Thomas Goirand wrote:
[...]
> Also, sdists are *not* "upstream-created source tarballs". I
> consider the binary form built for PyPi. Just like we have .debs,
> PyPi has tarballs and wheels, rather than how you describe them.
[...]

Upstream in OpenStack we believe we are distributing source tarballs
in sdist format. We produce and sign them, and serve them from
multiple locations. When you rebuild from a Git tag of an OpenStack
repository using a standard Python packaging ecosystem toolchain,
SetupTools is generating an ephemeral sdist on the fly in order to
set the metadata PBR and other components need.

I think it's fine that you'd rather rebuild the source distributions
from revision control than use the ones published by the OpenStack
community (we sign our tags with the same OpenPGP key as our
tarballs anyway), but it's merely your opinion that sdists are *not*
"upstream-created source tarballs" (an opinion *not* shared by
everyone).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Jeremy Stanley]

On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote:
[...]
> I think a shallow clone of depth 1 is sufficient, although that's not
> sufficient to get the correct version number from Git in all cases.
[...]

Some tools (python3-reno, for example) want to inspect the commits
and historical tags on branches, in order to do things like
assembling release notes documents. I don't know if any reno-using
projects packaged in Debian get release notes included, but if they
do then shallow clones would break that process. The python3-pbr
plugin also wants to look at commit messages on the current branch
since the most recent tag if its SemVer-based version-guessing kicks
in (typically if the current commit isn't tagged and the version
string hasn't been overridden with an envvar).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

New supply-chain security tool: backseat-signed

[kpcyrd]

Hello,

I'm going to keep this short, I've been writing a lot of text recently 
(which is quite exhausting, on top of my dayjob and all the code I wrote 
today afterwards. Apologies if you're still waiting for a reply in one 
of the other threads).


I figured out a somewhat straight-forward way to check if a given `git 
archive` output is cryptographically claimed to be the source input of a 
given binary package in either Arch Linux or Debian (or both).


I believe this to be the "reproducible source tarball" thing some people 
have been asking about. As explained in the README, I believe 
reproducing autotools-generated tarballs isn't worth everybody's time 
and instead a distribution that claims to build from source should 
operate on VCS snapshots instead of tarballs with 25k lines of 
pre-generated shell-script. Building from VCS snapshots is already the 
case  for a large number of Arch Linux packages (through auto-generated 
Github tarballs). Some packages have been actively converted to VCS 
snapshots by Arch Linux staff in response to the xz incident.


This tool highlights the concept of "canonical sources", which is 
supposed to give guidance on what to code review. This is also why I 
think code signing by upstream is somewhat low priority, since the big 
distros can form consensus around "what's the source code" regardless.


https://github.com/kpcyrd/backseat-signed

The README shows how to verify Arch Linux and Debian build cmatrix from 
the same source code - they may both still apply patches (which would be 
considered part of the build instructions), but the specified source 
input is the same. This tarball can also be bit-for-bit reproduced from 
VCS by taking a `git archive` snapshot of the v2.0 tag in the cmatrix 
repository.


(If somebody ever tells you programming in Rust is slower, I wrote the 
entirety of this codebase within a few hours of a single day)


Let me know what you think. 🖤

Happy feet,
kpcyrd

Re: Firmwares (was Re: Bits from the DPL)

[Dmitry Baryshkov]

On Mon, 1 Apr 2024 at 19:28, Vincent Bernat  wrote:
>
> On 2024-04-01 18:05, Jonathan Carter wrote:
> > The included firmware contributed to Debian 12 being a huge success,
> > but it wasn't the only factor.
>
> Unfortunately, the shipped firmwares are now almost a year old,
> including for unstable. I am following the progress since quite a few
> years and I have seen many possible contributors trying to help and
> fail. The current situation is that Debian does not work well with
> recent AMD-based laptops due to firmware being too old. Therefore, we
> are back at users trying to update the firmware by copying them from
> random places (as for myself, I am using the deb generated by upstream's
> Makefile).
>
> My personal impression is that we are repeating a common scheme in
> Debian: maintainers don't have time to move forward due to the task
> being non-trivial for reasons of our own, people are proposing to help
> (6 people in [1]), but this is ignored by the maintainers as they don't
> have time.

As one of the persons who tried and failed to do the update, I
wouldn't blame maintainers ignoring my PR. I would have appreciated
getting more prompt feedback, but I understand that we all are doing
this during our spare time.

There was another issue which I could not find my way through. I found
it pretty troublesome to update debian/config subdirs. There is no
clear reference whether the Version should follow the WHENCE or the
firmware version from the git commit message (they differ for Intel BT
files). So, my 2c, packaging infrastructure should use WHENCE file
where possible instead of duplicating a significant part of it.


-- 
With best wishes
Dmitry

Re: New supply-chain security tool: backseat-signed

[Adrian Bunk]

On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
>...
> I figured out a somewhat straight-forward way to check if a given `git
> archive` output is cryptographically claimed to be the source input of a
> given binary package in either Arch Linux or Debian (or both).

For Debian the proper approach would be to copy Checksums-Sha256 for the 
source package to the buildinfo file, and there is nothing where it would
matter whether the tarball was generated from git or otherwise.

> I believe this to be the "reproducible source tarball" thing some people
> have been asking about.
>...

The lack of a reliably reproducible checksum when using "git archive" is 
the problem, and git cannot realistically provide that.

Even when called with the same parameters, "git archive" executed in 
different environments might produce different archives for the same
commit ID.

It is documented that auto-generated Github tarballs for the same tag 
and with the same commit ID downloaded at different times might have 
different checksums.

> This tool highlights the concept of "canonical sources", which is supposed
> to give guidance on what to code review.
>...

How does it tell the git commit ID the tarball was generated from?

Doing a code review of git sources as tarball would would be stupid,
you really want the git metadata that usually shows when, why and by
whom something was changed.

> https://github.com/kpcyrd/backseat-signed
> 
> The README
>...

"This requires some squinting since in Debian the source tarball is 
 commonly recompressed so only the inner .tar is compared"

This doesn't sound true.

> Let me know what you think. 🖤
> 
> Happy feet,
> kpcyrd

cu
Adrian

Re: xz backdoor

[Robert Edmonds]

This backdoor abused the IFUNC mechanism in the GNU toolchain to hook into
the sshd process. Looking on my Debian sid workstation with about 1900 library
packages installed, I see a very small handful of source packages shipping
libraries with IFUNC symbols, mostly things like gcc, glibc, haskell, some Intel
GPU stuff, etc. [0]

I do not know enough about the underlying technology to guess why the attacker
chose to abuse the IFUNC mechanism versus, say, using the ELF .init_array
section to introduce an ordinary initialization function into the backdoor
library. (E.g., putting the equivalent of an __attribute__((constructor))
function in the compiled binary blob part of the backdoor.) Perhaps what the
attacker wanted to do was much easier to implement with the IFUNC mechanism to
the point that it justified the sourceful changes to the upstream repository.

If IFUNC symbols are sufficiently rare and sufficiently powerful, is it
worth implementing some hygiene around their proliferation in Debian? For
instance, something like a Lintian tag combined with an ftpmaster autoreject,
such as what we do for libraries that set RPATH?


[0] A quick and dirty way to check for IFUNC symbols in the libraries installed
on the system:

for fname in /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/*.so.*; do
echo "> ${fname} <"
readelf -X -s ${fname} | grep IFUNC
echo
done

-- 
Robert Edmonds
edmo...@debian.org

Re: xz backdoor

[Mike Hommey]

On Wed, Apr 03, 2024 at 02:01:23AM -0400, Robert Edmonds wrote:
> This backdoor abused the IFUNC mechanism in the GNU toolchain to hook into
> the sshd process. Looking on my Debian sid workstation with about 1900 library
> packages installed, I see a very small handful of source packages shipping
> libraries with IFUNC symbols, mostly things like gcc, glibc, haskell, some 
> Intel
> GPU stuff, etc. [0]
> 
> I do not know enough about the underlying technology to guess why the attacker
> chose to abuse the IFUNC mechanism versus, say, using the ELF .init_array
> section to introduce an ordinary initialization function into the backdoor
> library. (E.g., putting the equivalent of an __attribute__((constructor))
> function in the compiled binary blob part of the backdoor.) Perhaps what the
> attacker wanted to do was much easier to implement with the IFUNC mechanism to
> the point that it justified the sourceful changes to the upstream repository.

My understanding of the exploit is that the IFUNC initialization
function is run before relocated but read-only sections of the binary in
memory are actually made read-only (that is, it's run before relocation
is finished). That allows the exploit to overwrite GOT pointers.
Arguably, a contructor can still call mprotect and overwrite GOT
pointers, so there isn't a major advantage to use IFUNC over a more
traditional constructor. I guess there's an advantage in not changing
the pattern of syscalls called during library initialization to be more
stealthy, but OTOH, Firefox does two mprotect calls per library it loads
and nobody opened a bug about that behaviour on bugzilla.mozilla.org in
the close to 7 years it's been doing that (and don't worry, that's
expected, but also don't look at what Firefox does in unstable because
it doesn't do it anymore ; upstream builds still do ; if you're curious
about the details, see https://glandium.org/blog/?p=4297).

There's an argument to be done that read-only portions of binaries ought
to stay read-only (aka forbid mprotect).

Mike