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

[Howard Chu]

Damien Miller wrote:
> Another thing we're considering in OpenSSH is changing how we integrate
> with PAM. PAM's API demands loading modules into the authenticating
> process' address space, but obviously we've just been reminded that this
> is risky.

This was a long-standing problem with pam/nss-ldap, which we solved by moving 
all of the
actual libldap invocations to a separate nslcd process, and only communicated 
to it
across a unix domain socket via stubs in the pam/nss modules. Mixing instances 
of libraries
that applications call directly, with instances loaded implicitly by 
system-level mechanisms,
was always a bad idea and caused endless problems, even without malicious 
attackers.

> I think that I would prefer to move to a model where there PAM auth and
> account modules run in a helper process, and only the session module
> runs in the unprivileged post-auth sshd process.

We could probably generalize the stub wrapping that we used for nss/pam-ldapd / 
nslcd to
be a generic interface to a standalone pamd that actually loads the pam 
modules. Should
be a simple job.

> This means that PAM auth/account modules and their transitive library
> dependencies cannot affect the sshd address space. They would still
> likely need to run with privilege, could still fail permissively in
> unwanted situations and might still be able to cause problems directly
> (e.g. opening a reverse shell from the PAM module itself), but they
> would no longer have direct access to the contents of sshd network
> traffic, signatures, etc that are extremely useful in building NOBUS
> (https://en.wikipedia.org/wiki/NOBUS) backdoors like the xv one.
> 
> Where this gets challenging is that some PAM modules make assumptions
> that the auth, account and session modules all run in the same address
> space. These would break until re-architected to pass things explicitly,
> e.g. via environment variables, temp files, etc.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

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

[Sirius]

In days of yore (Tue, 02 Apr 2024), Colin Watson thus quoth: 
> TCP wrappers
> 

Not used hosts.{allow,deny} for the last 17 years (since I started my
current employment) so I am biased. Honest opinion is that firewall and
fail2ban have pretty much obsoleted TCP wrappers.

> SELinux
> ===
> 
> For the time being my inclination is to leave this be, but I've seen the
> suggestion that pam_selinux is basically all you need
> (https://infosec.exchange/@alwayscurious/112192949171400643), so maybe
> it would be an option to drop --with-selinux in favour of that?  I've
> never used SELinux, so I'd need an expert to weigh on here.

If you need an expert on SELinux, you need Dan Walsh.

I have used SELinux for the last 17 years, from when it was a monolithic
policy to what it is like today in RHEL. SELinux is - as far as I know -
not an issue and have a fail-close rather than fail-open approach. IMHO,
if it is not used and you have the time to spare to drop it, do, otherwise
it should be safe with the status-quo on this.

And should Debian pick SELinux up fully and enable a targeted policy,
well, you will want this anyway.

-- 
Kind regards,

/S

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

[Russ Allbery]

Christoph Anton Mitterer  writes:

> Actually I think that most sites where I "need"/use GSSAPI... only
> require the ticket for AFS, and do actually allow pubkey auth (but
> right now, one doesn't have AFS access then).

In past discussions of this patch, this has not been the case.  One of the
advantages of GSSAPI key exchange is that you can disable public keys for
all of your hosts and never manage known hosts, instead only using the
system Kerberos keytabs.  Since in a Kerberos environment you have to put
keytabs on every host *anyway*, and that *is* the host's identity in a
Kerberos environment, this reduces the number of key infrastructures you
have to manage by one, which matters to some Kerberos deployments.  This
arguably gives you better security in that specific environment because
keytabs do not rely on leap-of-faith initial authentication; the server is
always properly authenticated, even on first connect.

> Not sure if there's a simple out of the box way to just transfer that
> but without all the other GSSAPI stuff?

If you want your ticket to refresh remotely when you refresh it locally,
which is often needed for Kerberos applications like AFS, you do need key
exchange, since that's the mechanism that allows that to happen.

(I use both GSSAPI and tcpwrappers, so Colin's proposal would mean more
work for me, but given the situation, I'm willing to rework the way that I
use ssh to avoid both going forward.  More features are nice, but I can
see the merits of simplicity here.  But I no longer maintain a large
infrastructure built on Kerberos, so I'm not putting as much weight on the
GSSAPI support as I used to.)

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

Bug#1068215: ITP: python-undetected-chromedriver -- test undetected chromedrive

[Josenilson Ferreira da Silva]

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

* Package name: python-undetected-chromedriver
  Version : 3.5.5
  Upstream Contact: UltrafunkAmsterdam 
* URL : 
https://github.com/ultrafunkamsterdam/undetected-chromedriver
* License : GPL3
  Programming Lang: Python
  Description : test undetected chromedrive

  "undetected-chromedriver" is a project that offers a solution to a common
 problem among developers working on browser test automation using Selenium
 WebDriver.
 .
 The project aims to overcome problems related to test failures when websites
 detect the use of "WebDriver. The module provides a wrapper around
 ChromeDriver (the driver for controlling the Google Chrome browser vi
 a Selenium), which implements several techniques to avoid detection and
 ensure your automated tests run without interruption.
 .
 With an easy-to-use interface, undetected-chromedriver" enables integration
 with existing automation projects, supporting a variety of platforms and
 development environments, making it a versatile tool for developers seeking
 stability and reliability in automated testing
 .
 Note: This package is a required dependency for the TeraBoxUtility
 ITP package: #1067395

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

[Christoph Anton Mitterer]

Hey.

On Tue, 2024-04-02 at 01:30 +0100, Colin Watson wrote:
> 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.

Being one of those people, and having even asked for more patches to be
merged (#1053822) O:-) ... no, there was no social engineering
intended,... your approach sounds like a reasonable way to go.

Actually I think that most sites where I "need"/use GSSAPI... only
require the ticket for AFS, and do actually allow pubkey auth (but
right now, one doesn't have AFS access then).
Not sure if there's a simple out of the box way to just transfer that
but without all the other GSSAPI stuff?

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?


Cheers,
Chris.

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

[Damien Miller]

On Tue, 2 Apr 2024, Colin Watson wrote:

[I'm not subscribed to the debian-* lists, please Cc me in replies if
you want me to see them]

> [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.]

Thanks Colin for considering how to reduce dependency chains for sshd.
I just remembered that this is not the first time that sshd has been
attacked via a transitive library dependency - it has happened before,
about 10 years ago:

https://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/

Attacks like these are impossible for sshd to defend against itself.
Instead we have to look to minimising the number of libraries that end
up in sshd's address space, especially that of the privileged sshd
process.

We are currently exploring splitting sshd into separate binaries for
the listener, privileged monitor, pre- and post-auth network-facing
processes so that each can be reduced in size and functionality to
the minimum possible. This should remove a number of dependencies from
the privileged process. There's a draft of these changes at
https://github.com/djmdjm/openssh-wip/pull/26 but it's OpenBSD-only
at this stage. We're likely to proceed with splitting the listener
process from the rest of sshd hopefully before the next release.

Another thing we're considering in OpenSSH is changing how we integrate
with PAM. PAM's API demands loading modules into the authenticating
process' address space, but obviously we've just been reminded that this
is risky.

I think that I would prefer to move to a model where there PAM auth and
account modules run in a helper process, and only the session module
runs in the unprivileged post-auth sshd process.

This means that PAM auth/account modules and their transitive library
dependencies cannot affect the sshd address space. They would still
likely need to run with privilege, could still fail permissively in
unwanted situations and might still be able to cause problems directly
(e.g. opening a reverse shell from the PAM module itself), but they
would no longer have direct access to the contents of sshd network
traffic, signatures, etc that are extremely useful in building NOBUS
(https://en.wikipedia.org/wiki/NOBUS) backdoors like the xv one.

Where this gets challenging is that some PAM modules make assumptions
that the auth, account and session modules all run in the same address
space. These would break until re-architected to pass things explicitly,
e.g. via environment variables, temp files, etc.

Time permitting, I'll get a prototype of these changes made for wider
experimentation.

-d

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

[Colin Watson]

[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 it would make continuing to build the default variant using
--with-kerberos5 more palatable, since then the extra non-trivial
linkage would only affect people who turn on those options.


TCP wrappers


We carry a 

Bug#1068212: ITP: python-grpcio-status -- Status proto mapping for gRPC

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-devel@lists.debian.org, kd8...@gmail.com

* Package name: python-grpcio-status
  Version : 1.62.1
  Upstream Contact: The gRPC Authors 
* URL : https://github.com/OctopusAI/grpcio-status
* License : Apache-2.0
  Programming Lang: Python
  Description : Status proto mapping for gRPC

gRPC Python Status Proto is a reference package for GRPC Python
 status proto mapping. Planned to maintain it under DPT, and need
 a sponsor.

Re: Validating tarballs against git repositories

[Gioele Barabucci]

On 31/03/24 08:59, Sven Joachim wrote:

The coreutils bootstrap script fetches files over the network, so it is
not possible to build the Debian package from upstream git tags.  At the
very least it would lack any translations, and there is also the
problem of the gnulib submodule.

Aren't these the same kinds of problem that affect go and rust packages?

--
Gioele Barabucci

Bug#1068206: ITP: jolt -- A multi core friendly rigid body physics and collision detection library, written in C++, suitable for games and VR applications.

[Bret Curtis]

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

* Package name: jolt
  Version : 4.0.2
  Upstream Contact: Jorrit Rouwe 
* URL : https://github.com/jrouwe/JoltPhysics
* License : MIT
  Programming Lang: C++
  Description : A multi core friendly rigid body physics and collision 
detection library, written in C++, suitable for games and VR applications.

A multi core friendly rigid body physics and collision detection library 
suitable for games and VR applications, used by Horizon Forbidden West.

Extra Info:
This is already in use by several other project, of which is OpenMW which will 
eventually require this physics library.

Debian packaging for git-credential-libsecret

[M Hickford]

Hi. It'd be great to package Git credential helper
git-credential-libsecret in Debian. There's a patch prepared, but it
needs the attention of a Debian developer. Is anyone here able to
help?  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878599

Kind regards
-M

Re: Bits from the DPL

[Christian Kastner]

Hi Jonathan,

just a brief correction:

On 2024-04-01 18:05, Jonathan Carter wrote:
> I don't want to single out DSA there, it's difficult and affects many
> other teams. The Salsa CI team also spent a lot of resources (time and
> money wise) to extend testing on AMD GPUs and other AMD hardware. It's
> fantastic and interesting work, and really more people within the
> project and in the outside world should know about it!

The AMD GPUs are not part of the official CI yet, as both our official
infrastructure (hosting the GPUs) and our policies (expressing hardware
relationships) do not permit it.

We are running a fork of debci and other packages at
https://ci.rocm.debian.net. Our forks have a number of experimental
features, notably our architectures are [CPU ISA]+[GPU ISA], for example
amd64+gfx1030 (Navi 21) or amd64+gfx1100 (Navi 31).

Our fork currently automatically tracks all Debian packages which
reverse-depend on any of our libraries. Developers are invited to add
ROCm support to their packages if it's supported upstream, and the
packages will automatically be tested on over a dozen AMD GPU
architectures within our infra.

We're finalizing our upgrade to ROCm 5.7+ (also on Ubuntu), and a proper
write-up will follow on Debian Planet.

Best,
Christian

PS: Our intention is of course to feed back all our changes to debci,
Policy and so on, but some of these are entirely novel and require
experimentation first, followed by discussion.

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

[Guillem Jover]

Hi!

On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> Let's try to go in detail on how this was done on the build system
> side (I'm doing this right now, as previously only had skimmed over
> the process).
> 
> The build system hook was planted in the tarball by adding a modified
> m4/build-to-host.m4 file. This file is originally from gnulib (but
> gettext would usually embed it if it required it). The macros contained
> within are used by m4/gettext.m4 coming from gettext.
> 
> So to start with, this dependency (the AM_GNU_GETTEXT macro uses
> gl_BUILD_TO_HOST) is only present with newer gettext versions. The
> tarball was autoreconf'ed with gettext 0.22.4, Debian has gettext 0.21,
> which does not pull that dependency in. In that case if gettext.m4
> would get modified in this build now, then the hook would be inert,
> but once we update to a newer gettext then it would get activated
> again.
> 
> The m4/build-to-host.m4 file in addition to hooking the payload into
> the build system, also got its serial number bumped from 3 to 30.
> 
> And the bigger issue is that «autoreconf -f -i» does not even refresh
> the files (as you'd expect from the --force), if the .m4 serial is higher.
> So in Debian currently, the gettext.m4 in the tarball does not get
> refreshed (still pulling in the malicious build-to-host.m4, which
> would not happen with the gettext version from Debian), and if we
> updated to a newer gettext then it would not update build-to-host.m4
> anyway due to its bumped serial.
> 
> 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. :/

I filed a report to autoconf upstream at:

  https://lists.gnu.org/archive/html/bug-autoconf/2024-03/threads.html

the discussion now continues on the next month archive at:

  https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg3.html

We might have to perform a mass rebuild to check if there could be
fallout out of a true --force behavior change I guess.

Thanks,
Guillem

Re: Validating tarballs against git repositories

[Bastian Blank]

On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote:
> On 2024-04-01 12:44, Bastian Blank wrote:
> > So in the end you still need to manually review all the stuff that the
> > tarball contains extra to the git.  And for that I don't see that it
> > actually gives some helping hands and makes it easier.
> > 
> > So I really don't see how this makes the problem in hand any better.
> > Again the workload of review is on the person doing the job.  Aka we do
> > fragile manual work instead of possibly failing automatic work.
> 
> I think that if Debian was using git instead of the generated tarball, this
> part of the backdoor would have just been included in the git repository as
> well. If we were able to magically switch everything to git (and we won't,
> we are not even able to agree on simpler stuff), I don't think it would have
> prevented the attack.

Nothing prevents such an attack.  Prevent would be a 100% fix, which can
not exist.  However what we can do is to make it harder to pull off.

If they had been forced to commit all the activation code into the repo,
it would have been directly visible for everyone.  But instead, they
choose to only ship it in the tarballs.

That's why I asked if this would make it better, by removing this manual
review task from the maintainer.

Bastian

-- 
I object to intellect without discipline;  I object to power without
constructive purpose.
-- Spock, "The Squire of Gothos", stardate 2124.5

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

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 06:27:29PM +0200, 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.
> 
> [1]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests
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).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Theodore Ts'o]

On Mon, Apr 01, 2024 at 04:47:05PM +0100, Colin Watson wrote:
> On Mon, Apr 01, 2024 at 08:13:58AM -0700, Russ Allbery wrote:
> > Bastian Blank  writes:
> > > I don't understand what you are trying to say.  If we add a hard check
> > > to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
> > > if the upload is a tarball or git.
> > 
> > Er, well, there goes every C package for which I'm upstream, all of which
> > have M4 macros in m4/* that do not come from an external source.
> 
> Ditto.  And a bunch of the packages where I'm not upstream too, such as
> that famously enthusiastic adopter of all things GNU, OpenSSH.

For e2fsprogs, almost all the M4 macros come from an external source;
but I had to patch one of the macros so that it would work on *BSD
when using pmake as opposed to GNU make.  And in another case, I
copied the macro from another package's git repo to fix a portability
issue with Mac OS X.

So it's highly likely that if you added a hard check in Lintian, both
of these would trigger for e2fsprogs.

Portability is hard.  Let's go shopping!

- Ted

Re: Validating tarballs against git repositories

[Theodore Ts'o]

On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote:
>
> I think that if Debian was using git instead of the generated tarball, this
> part of the backdoor would have just been included in the git repository as
> well. If we were able to magically switch everything to git (and we won't,
> we are not even able to agree on simpler stuff), I don't think it would have
> prevented the attack.

I'm not sure how much it would have helped, but I think the theory
behind eliminating the gap between the release tarball and the git
tree is the theory that in 2024, more developers are more likely to be
building and testing against the git tree, and so it might have been
more likely noticed.  After all, Jia Tan decided it was worth while to
check in 99% of the exploit in git, but to only enable it when it was
built from the release tarball.  If the exploit was always active when
built from the git tree, perhaps someone might have noticed before it
Debian uploaded the trojan'ed binary package to unstable, and then a
week or so later, having it promoted to testing.

I'm not sure how likely that would be for the specific case of
xz-utils, since it appears the number of developers (not just
Maintainers) was extremely small, but presumably Jia Tan decided to do
things in that way in the hopes of making less likely that the malware
would be noticed.

- Ted

Re: Validating tarballs against git repositories

[Vincent Bernat]

On 2024-04-01 12:44, Bastian Blank wrote:


So in the end you still need to manually review all the stuff that the
tarball contains extra to the git.  And for that I don't see that it
actually gives some helping hands and makes it easier.

So I really don't see how this makes the problem in hand any better.
Again the workload of review is on the person doing the job.  Aka we do
fragile manual work instead of possibly failing automatic work.


I think that if Debian was using git instead of the generated tarball, 
this part of the backdoor would have just been included in the git 
repository as well. If we were able to magically switch everything to 
git (and we won't, we are not even able to agree on simpler stuff), I 
don't think it would have prevented the attack.

Firmwares (was Re: Bits from the DPL)

[Vincent Bernat]

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.


[1]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests

Re: Validating tarballs against git repositories

[Colin Watson]

On Mon, Apr 01, 2024 at 05:24:45PM +0200, Simon Josefsson wrote:
> Colin Watson  writes:
> > On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
> >> Running ./bootstrap in a tarball may lead to different results than the
> >> maintainer running ./bootstrap in pristine git.  It is the same problem
> >> as running 'autoreconf -fvi' in a tarball does not necessarily lead to
> >> the same result as the maintainer running 'autoreconf -fvi' from
> >> pristine git.  The different is what is pulled in from the system
> >> environment.  Neither tool was designed to be run from within a tarball,
> >> so this is just bad practice that never worked reliable and without a
> >> lot of complexity it will likely not become reliable either.
> >
> > The practice of running "autoreconf -fi" or similar via dh-autoreconf
> > has worked extremely well at scale in Debian.  I'm sure there are
> > complex edge cases where it's caused problems, but it's far from being a
> > disaster area.
> 
> Agreed.  I'm saying it doesn't fix the problem that I perceive that some
> people appear to believe, i.e., that running 'autoreconf -fi' solves the
> re-bootrapping problem.

Indeed - I've been pointing this out to people pretty much since the
xz-utils backdoor was discovered.

> >> I have suggested before that upstream's (myself included) should publish
> >> PGP-signed *-src.tar.gz tarballs that contain the entire pristine git
> >> checkout including submodules,
> >
> > A while back I contributed support to Gnulib's bootstrap script to allow
> > pinning particular commits without using submodules.  I would recommend
> > this mode; submodules have very strange UI.
> 
> I never liked git submodules generally, so I would be happy to work on
> getting that to be supported -- do you have pointers for earlier works
> here?

https://lists.gnu.org/archive/html/bug-gnulib/2018-04/msg00029.html and
thread - it's been in gnulib for some years.  (I think you may have
misread me as saying that I'd tried to contribute this and that it never
made it, or something like that?)

> What is necessary, I think, is having something like this in
> bootstrap.conf:
> 
> gnulib_commit_id = 123abc567...

This is what I implemented, except I spelled it GNULIB_REVISION.  Then
see e.g.
https://gitlab.com/libpipeline/libpipeline/-/blob/main/bootstrap.conf.

> > As I noted in a comment on your blog, I think there is a case to be made
> > for .po files being committed to upstream git, and I'm not fond of the
> > practice of pulling them in only at bootstrap time (although I can
> > understand why that's come to be popular as a result of limited
> > maintainer time).  I have several reasons to believe this:
> 
> Those are all good arguments, but it still feels backwards to put these
> files into git.  It felt so good to externalize all the translation
> churn outside of my git (or then, CVS...) repositories many years ago.
> 
> I would prefer to maintain a po/SHA256SUMS in git and continue to
> download translations but have some mechanism to refuse to continue if
> the hashes differ.

I wonder if a middle ground would be automated commits of translations.
I don't think that's as robust, but a number of projects do it (e.g.
d-i) and at least it's amenable to having translations go through CI
rather than just being YOLOed straight into release tarballs.

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

Re: xz backdoor

[Adrian Bunk]

On Mon, Apr 01, 2024 at 12:02:09PM +0200, Bastian Blank wrote:
> Hi
> 
> On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > > What we can do unilaterally is to disallow vendoring those files.
> > These files are supposed to be vendored in release tarballs,
> > the sane approach for getting rid of such vendored files would
> > be to discourage tarball uploads to the archive and encourage
> > git uploads instead.
> 
> I don't understand what you are trying to say.  If we add a hard check
> to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
> if the upload is a tarball or git.

xz also has > 600 LOC of legit own m4 code in m4/*,
and that's not unusual for packages using autoconf.

> > > Does it help?  At least in the case of autoconf it removes one common
> > > source of hard to read files.
> > But I doubt every DD would be able to review the 2k LOC non-vendored 
> > autoconf code in xz.
> 
> But at least changes to this code are visible.  In this case the changes
> to the m4 stuff did not exist in the somewhat reviewed repo, but just in
> the unreviewed tarballs.

There are many other ways how these unreviewed tarballs could be manipulated.

The root cause of the problem you want to solve is that the ftp team 
permits uploading such unreviewed tarballs to our archive.

> Bastian

cu
Adrian

Re: xz backdoor

[Colin Watson]

On Mon, Apr 01, 2024 at 08:13:58AM -0700, Russ Allbery wrote:
> Bastian Blank  writes:
> > I don't understand what you are trying to say.  If we add a hard check
> > to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
> > if the upload is a tarball or git.
> 
> Er, well, there goes every C package for which I'm upstream, all of which
> have M4 macros in m4/* that do not come from an external source.

Ditto.  And a bunch of the packages where I'm not upstream too, such as
that famously enthusiastic adopter of all things GNU, OpenSSH.

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

Re: Validating tarballs against git repositories

[Simon Josefsson]

Colin Watson  writes:

> On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
>> Running ./bootstrap in a tarball may lead to different results than the
>> maintainer running ./bootstrap in pristine git.  It is the same problem
>> as running 'autoreconf -fvi' in a tarball does not necessarily lead to
>> the same result as the maintainer running 'autoreconf -fvi' from
>> pristine git.  The different is what is pulled in from the system
>> environment.  Neither tool was designed to be run from within a tarball,
>> so this is just bad practice that never worked reliable and without a
>> lot of complexity it will likely not become reliable either.
>
> The practice of running "autoreconf -fi" or similar via dh-autoreconf
> has worked extremely well at scale in Debian.  I'm sure there are
> complex edge cases where it's caused problems, but it's far from being a
> disaster area.

Agreed.  I'm saying it doesn't fix the problem that I perceive that some
people appear to believe, i.e., that running 'autoreconf -fi' solves the
re-bootrapping problem.  Only some files get re-generated, such as the
./configure script, which is good, but not all files.  It wouldn't have
solved the xz case: build-to-host.m4 wouldn't have been re-generated.

With a *-src.tar.gz approach [1], the build-to-host.m4 file shouldn't
even be part of the tarball.  That would be easier to detect during an
audit of list of files compared to git repository, rather than waiting
for code review of file content (which usually only happens when
debugging some real-world problem).

[1] 
https://blog.josefsson.org/2024/04/01/towards-reproducible-minimal-source-code-tarballs-please-welcome-src-tar-gz/

> I don't think running ./bootstrap can be generalized as easily as
> running autoreconf can, and it's definitely going to be tough to apply
> to all packages that use gnulib; but I think the blanket statement that
> it's bad practice is painting with too broad a brush.  For the packages
> where I've applied it so far (most of which I'm upstream for,
> admittedly), it's fine.

I'm not saying autoreconf -fi is bad practice, I'm saying it is
incomplete and leads to a feeling of having solved the re-bootstrapping
problem that isn't backed by facts.

>> I have suggested before that upstream's (myself included) should publish
>> PGP-signed *-src.tar.gz tarballs that contain the entire pristine git
>> checkout including submodules,
>
> A while back I contributed support to Gnulib's bootstrap script to allow
> pinning particular commits without using submodules.  I would recommend
> this mode; submodules have very strange UI.

I never liked git submodules generally, so I would be happy to work on
getting that to be supported -- do you have pointers for earlier works
here?

What is necessary, I think, is having something like this in
bootstrap.conf:

gnulib_commit_id = 123abc567...

and it would then use the external git repository pointed to by
--gnulib-refdir and locate that commit, and extract the gnulib files
from that gnulib commit.  And refuse to continue if it can't find that
particular commit.

This is essentially the same as a git submodule -- encoding the gnulib
commit to use in the project's own git history -- but without the bad
git submodule user experience.

I use different approaches to gnulib in projects. In OATH Toolkit I
still put all gnulib-generated content in git because running
./bootstrap otherwise used to take several minutes.  In most projects I
have given up and use git submodules.  In some I rely on running
gnulib-tool from git, and the exact gnulib git commit to use is only
whatever I happened to have checked out on my development machine.

>> *.po translations,
>
> As I noted in a comment on your blog, I think there is a case to be made
> for .po files being committed to upstream git, and I'm not fond of the
> practice of pulling them in only at bootstrap time (although I can
> understand why that's come to be popular as a result of limited
> maintainer time).  I have several reasons to believe this:

Those are all good arguments, but it still feels backwards to put these
files into git.  It felt so good to externalize all the translation
churn outside of my git (or then, CVS...) repositories many years ago.

I would prefer to maintain a po/SHA256SUMS in git and continue to
download translations but have some mechanism to refuse to continue if
the hashes differ.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Theodore Ts'o]

On Sat, Mar 30, 2024 at 08:44:36AM -0700, Russ Allbery wrote:
> Luca Boccassi  writes:
> 
> > In the end, massaged tarballs were needed to avoid rerunning autoconfery
> > on twelve thousands different proprietary and non-proprietary Unix
> > variants, back in the day. In 2024, we do dh_autoreconf by default so
> > it's all moot anyway.
> 
> This is true from Debian's perspective.  This is much less obviously true
> from upstream's perspective, and there are some advantages to aligning
> with upstream about what constitutes the release artifact.

My upstream perspective is that I've burned repeatedly with
incompatible version changes in autotools programs which causes my
configure.{in,ac} file to no longer create a working configure script,
or which causes subtle breakages.  So my practice is to use autoconf
on my Debian testing development system before checking in the
configure.ac and configure files --- but I ship the generated files
and I don't tell people to run autoreconf before running ./configure.
And if things break after they run autoreconf, I tell them, "you ran
autoreconf; you get to keep both pieces".

And there *have* been times when autoconf has gotten updated in Debian
testing, and the resulting configure script has broken, at which point
I curse at autotools, and fix the configure.ac and/or aclocal.m4
files, etc., and *then* check in the generated configure file and
autotool source files.

> 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.

> 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.
It hasn't been *all* that long ago that I started require C99
compilers

That being said, if someone who was worried about an Jia Tan-style
attack with e2fsprogs, first of all, you can verify that configure
corresponds to autoconf on the Debian testing at the time when the
archive was generated, and the officially released tar file is
generated via:

git archive --prefix=e2fsprogs-${ver}/ ${commit} | gzip -9n > $fn

... and the release tarballs are also in the pristine-tar branch of
e2fsprogs.  So even if kernel.org (preferred) and sourceforget.net
(legacy) servers for the e2fsprogs tar files completely implodes, and
you only have access to the git repo, you can still get the original
e2fsprogs tar files using pristine-tar.

- Ted

Re: xz backdoor

[Russ Allbery]

Bastian Blank  writes:

> I don't understand what you are trying to say.  If we add a hard check
> to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
> if the upload is a tarball or git.

Er, well, there goes every C package for which I'm upstream, all of which
have M4 macros in m4/* that do not come from an external source.

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

Re: Command /usr/bin/mv wrong message in German

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 05:02:56PM +0200, Fabrice Aeschbacher wrote:
> "dpkg -S" or "apt-file" give me an incorrect or no answer, most of the
> times.
> 
> Whereas this url always returns a correct answer:
> https://www.debian.org/distrib/packages#search_contents
Have you tried either of two examples you quoted?


> Le 01/04/2024 à 09:58, Andrey Rakhmatullin a écrit :
> > On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:
> > > On 1/4/24 10:18, gregor herrmann wrote:
> > > > % dpkg -S $(which mv > coreutils: /usr/bin/mv
> > > On bookworm:
> > > 
> > >  $ dpkg -S $(which mv)
> > >  dpkg-query: no path found matching pattern /usr/bin/mv
> > > 
> > > This is caused by the /bin -> /usr/bin shift.
> > > 
> > > The reason I'm replying is after one, probably two decades this still
> > > annoys me:
> > > 
> > > $ dpkg -S /etc/profile
> > > dpkg-query: no path found matching pattern /etc/profile
> > > 
> > > It was put their by the Debian install, and I'm unlikely to change it.
> > > Its fairly important security wise.  It would be nice if "dpkg -S" told
> > > me base-files.deb installed it.  It would be nice if debsums told me if
> > > it changed.  There are lots of files like this, such as /etc/environment
> > > and /etc/hosts.  There are some directories like /etc/apt/trusted.gpg.d/
> > > which should only have files claimed by some .deb.
> > This is the reason I never expect dpkg -S to work and dpkg -L to be
> > correct. The (probably) oldest registered bug report about this is
> > #213907, from 2003.
> > RPM has %ghost since before that, of course.
> > 
> 
> 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Command /usr/bin/mv wrong message in German

[Fabrice Aeschbacher]

"dpkg -S" or "apt-file" give me an incorrect or no answer, most of the 
times.


Whereas this url always returns a correct answer:
https://www.debian.org/distrib/packages#search_contents

Best,
Fabrice


Le 01/04/2024 à 09:58, Andrey Rakhmatullin a écrit :

On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:

On 1/4/24 10:18, gregor herrmann wrote:

% dpkg -S $(which mv > coreutils: /usr/bin/mv

On bookworm:

 $ dpkg -S $(which mv)
 dpkg-query: no path found matching pattern /usr/bin/mv

This is caused by the /bin -> /usr/bin shift.

The reason I'm replying is after one, probably two decades this still
annoys me:

$ dpkg -S /etc/profile
dpkg-query: no path found matching pattern /etc/profile

It was put their by the Debian install, and I'm unlikely to change it.
Its fairly important security wise.  It would be nice if "dpkg -S" told
me base-files.deb installed it.  It would be nice if debsums told me if
it changed.  There are lots of files like this, such as /etc/environment
and /etc/hosts.  There are some directories like /etc/apt/trusted.gpg.d/
which should only have files claimed by some .deb.

This is the reason I never expect dpkg -S to work and dpkg -L to be
correct. The (probably) oldest registered bug report about this is
#213907, from 2003.
RPM has %ghost since before that, of course.

Re: Validating tarballs against git repositories

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 04:10:55PM +0200, Alexandre Detiste wrote:
> Le lun. 1 avr. 2024 à 15:49, Colin Watson  a écrit :
> >
> > The practice of running "autoreconf -fi" or similar via dh-autoreconf
> > has worked extremely well at scale in Debian.  I'm sure there are
> > complex edge cases where it's caused problems, but it's far from being a
> > disaster area.
> 
> It's pretty uncommon, only old stuff.
> 
> That could be monitored (via lintian ?),
> anything with "--without autoreconf"
> or "overides dh_autoreconf".
Or compat < 10.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Alexandre Detiste]

Le lun. 1 avr. 2024 à 15:49, Colin Watson  a écrit :
>
> The practice of running "autoreconf -fi" or similar via dh-autoreconf
> has worked extremely well at scale in Debian.  I'm sure there are
> complex edge cases where it's caused problems, but it's far from being a
> disaster area.

It's pretty uncommon, only old stuff.

That could be monitored (via lintian ?),
anything with "--without autoreconf"
or "overides dh_autoreconf".

grep autoreconf */debian/rules
enigma/debian/rules:override_dh_autoreconf:
enigma/debian/rules:#dh_autoreconf
geki2/debian/rules: dh $@ --no-parallel --without autoreconf
kanatest/debian/rules:execute_before_dh_autoreconf:
lincity-ng/debian/rules:dh $@ --without autoreconf

Re: Validating tarballs against git repositories

[Colin Watson]

On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
> Running ./bootstrap in a tarball may lead to different results than the
> maintainer running ./bootstrap in pristine git.  It is the same problem
> as running 'autoreconf -fvi' in a tarball does not necessarily lead to
> the same result as the maintainer running 'autoreconf -fvi' from
> pristine git.  The different is what is pulled in from the system
> environment.  Neither tool was designed to be run from within a tarball,
> so this is just bad practice that never worked reliable and without a
> lot of complexity it will likely not become reliable either.

The practice of running "autoreconf -fi" or similar via dh-autoreconf
has worked extremely well at scale in Debian.  I'm sure there are
complex edge cases where it's caused problems, but it's far from being a
disaster area.

I don't think running ./bootstrap can be generalized as easily as
running autoreconf can, and it's definitely going to be tough to apply
to all packages that use gnulib; but I think the blanket statement that
it's bad practice is painting with too broad a brush.  For the packages
where I've applied it so far (most of which I'm upstream for,
admittedly), it's fine.

> I have suggested before that upstream's (myself included) should publish
> PGP-signed *-src.tar.gz tarballs that contain the entire pristine git
> checkout including submodules,

A while back I contributed support to Gnulib's bootstrap script to allow
pinning particular commits without using submodules.  I would recommend
this mode; submodules have very strange UI.

> *.po translations,

As I noted in a comment on your blog, I think there is a case to be made
for .po files being committed to upstream git, and I'm not fond of the
practice of pulling them in only at bootstrap time (although I can
understand why that's come to be popular as a result of limited
maintainer time).  I have several reasons to believe this:

 * There at least used to be some edge cases where format string
   mismatches aren't caught by the gettext toolchain.  I've forgotten
   the details, but I remember running into one case where this turned
   into at least a translation-induced crash if not a security
   vulnerability.

 * Like just about everyone, translators make mistakes.  Since they're
   often working with technical text across a wide variety of domains,
   my experience is that they're more likely to make mistakes when
   dealing with package-specific terms, and these are often left
   untranslated, which means that the maintainer is in a much better
   position to catch those mistakes than you might think.  I don't want
   to cast shade on anyone in particular, but I find that I catch
   mistakes in a significant fraction of man-db translation updates just
   by looking at the diff without having to understand the target
   language; for example, if I add an item to a list and also make some
   other nearby textual changes, it's quite common for translators to
   miss adding the item to the list, and I can spot that sort of thing
   almost regardless of the language.

 * Actively malicious translations are rare, but they do happen.
   
https://discourse.ubuntu.com/t/announcement-ubuntu-desktop-23-10-release-image-translation-incident-now-resolved/39365
   was a recent case of this.  I seem to remember that when I tracked
   down the original files it was fairly obvious that the "translations"
   had nothing to do with the source strings even without understanding
   Ukrainian.

 * If you're faced with a user report containing translated messages,
   then it's much easier to figure out what's going on if you can just
   look for them in git.  I've found this to be a source of frustration
   on several occasions when dealing with packages where ./bootstrap
   pulls in translations.

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

Re: Command /usr/bin/mv wrong message in German

[Alexandre Detiste]

Le lun. 1 avr. 2024 à 10:43, Johannes Schauer Marin Rodrigues
 a écrit :
> > This is the reason I never expect dpkg -S to work and dpkg -L to be
> > correct. The (probably) oldest registered bug report about this is #213907,
> > from 2003. RPM has %ghost since before that, of course.
>
> This is the reason I never expect apt-file search to work. It would be nice if
> we had a tool which would track the files created by maintainer scripts as 
> well
> and associate them to packages. Isn't dumat tracking which files are actually
> created after package installation? If yes, can that data be made searchable?

That tool is cruft-ng ...

I mostly use it for forensics of messed up OS images,
but it can be asked where a single ghost/volatile file comes from.
(If it has been teached so)

$ LANG=C dpkg -S /etc/fstab
dpkg-query: no path found matching pattern /etc/fstab
$ cruft /etc/fstab
base-files

Greetings

Re: xz backdoor

[Pierre-Elliott Bécue]

De : Ansgar 🙀 
À : Pierre-Elliott Bécue ; Luca Boccassi 
Cc : debian-devel@lists.debian.org
Date : 1 avr. 2024 12:47:52
Objet : Re: xz backdoor

> 
> Hi,
> 
> On Sun, 2024-03-31 at 14:34 +0200, Pierre-Elliott Bécue wrote:
>> The PGP submodule of a Yubikey can host 3 keys, one signing, one
>> authent, and one encrypt. ISTR accessing the signing key is always
>> prompting for the PIN. Same for the encryption key. (I think both can
>> be configured otherwise)
> 
> I think presence confirmation is more useful, that is, interacting
> physically with the device for each signature.  The Yubikey can do that
> also for OpenPGP:
> 
> ```
> $ ykman openpgp keys set-touch --help
> [...]
>   Touch policies:
> 
>   Off (default)   no touch required
>   On  touch required
>   Fixed   touch required, can't be disabled without deleting the 
> private key
>   Cached  touch required, cached for 15s after use
>   Cached-Fixed    touch required, cached for 15s after use, can't be disabled
>   without deleting the private key
> ```
> 
> (The PIN can still be cached.)
> 
> For OpenSSH it might also be more convenient to use Webauthn, that is,
> the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`.
> 
> Ansgar
>> 
Yes, I did not mention the touch policy because right now I fail to have it 
enforced by the Yubi after having set it.

-- 
Pierre-Elliott Bécue

Re: xz backdoor

[Bastian Blank]

Hi

On Mon, Apr 01, 2024 at 12:40:51PM +0200, Ansgar 🙀 wrote:
> For OpenSSH it might also be more convenient to use Webauthn, that is,
> the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`.

Also those key types allow two different uses.  Persistent or
non-persistent keys differ in where parts of the key is stored and
protected.

Persistent keys store the second part on the hardware itself.  So you
can extract that part if you know the PIN of the hardware.  I for
example have one for access to my emails and irc system.

Non-persistent keys store the second part on the using system, aka your
hard drive.  Those files can optionally be protected with a standard SSH
passphrase.  You can also have many different keys this way.

But please be aware: resetting the fido part of a yubikey is pretty easy
and will immediatelly make all keys unusable.

Bastian

-- 
Punishment becomes ineffective after a certain point.  Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7

Re: Validating tarballs against git repositories

[Bastian Blank]

On Mon, Apr 01, 2024 at 12:03:48PM +0200, Bastian Blank wrote:
> On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> > That's not mutually exclusive. When adding an additional git remote
> > and using gbp-import-orig's --upstream-vcs-tag you get the best of
> > both worlds.
> And this will error out if there are unexpected changes in the tarball?
> How will it be able to detect those?

Okay, I looked into what it does.  It just adds another parent to the
commit with the import of the tar.  It does nothing else with this
information.

So in the end you still need to manually review all the stuff that the
tarball contains extra to the git.  And for that I don't see that it
actually gives some helping hands and makes it easier.

So I really don't see how this makes the problem in hand any better.
Again the workload of review is on the person doing the job.  Aka we do
fragile manual work instead of possibly failing automatic work.

Bastian

-- 
Women professionals do tend to over-compensate.
-- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before",
   stardate 1312.9.

Re: xz backdoor

[Ansgar 🙀]

Hi,

On Sun, 2024-03-31 at 14:34 +0200, Pierre-Elliott Bécue wrote:
> The PGP submodule of a Yubikey can host 3 keys, one signing, one
> authent, and one encrypt. ISTR accessing the signing key is always
> prompting for the PIN. Same for the encryption key. (I think both can
> be configured otherwise)

I think presence confirmation is more useful, that is, interacting
physically with the device for each signature.  The Yubikey can do that
also for OpenPGP:

```
$ ykman openpgp keys set-touch --help
[...]
  Touch policies:

  Off (default)   no touch required
  On  touch required
  Fixed   touch required, can't be disabled without deleting the 
private key
  Cached  touch required, cached for 15s after use
  Cached-Fixedtouch required, cached for 15s after use, can't be disabled
  without deleting the private key
```

(The PIN can still be cached.)

For OpenSSH it might also be more convenient to use Webauthn, that is,
the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`.

Ansgar
> 

Re: xz backdoor

[Iustin Pop]

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?

Looking forward to having up-to-date documentation once the dust
settles. I have enough yubikeys which are only used for 2FA.

(Well, and I'd need an airgapped, separate system, which I don't have)

thanks,
iustin

Re: Validating tarballs against git repositories

[Bastian Blank]

On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> That's not mutually exclusive. When adding an additional git remote
> and using gbp-import-orig's --upstream-vcs-tag you get the best of
> both worlds.

And this will error out if there are unexpected changes in the tarball?
How will it be able to detect those?

Bastian

-- 
I've already got a female to worry about.  Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0

Re: xz backdoor

[Bastian Blank]

Hi

On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > What we can do unilaterally is to disallow vendoring those files.
> These files are supposed to be vendored in release tarballs,
> the sane approach for getting rid of such vendored files would
> be to discourage tarball uploads to the archive and encourage
> git uploads instead.

I don't understand what you are trying to say.  If we add a hard check
to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
if the upload is a tarball or git.

> > Does it help?  At least in the case of autoconf it removes one common
> > source of hard to read files.
> But I doubt every DD would be able to review the 2k LOC non-vendored 
> autoconf code in xz.

But at least changes to this code are visible.  In this case the changes
to the m4 stuff did not exist in the somewhat reviewed repo, but just in
the unreviewed tarballs.

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6

Re: xz backdoor

[Stephan Verbücheln]

On Mon, 2024-04-01 at 10:59 +0200, tho...@goirand.fr wrote:
> Only for the signing operation, one can turn on the "force-sig"
> option so that the key always prompt for a pin. And that is not the
> default.

There are two levels. In the OpenPGP protocol, the smartcard can be
configured to require the PIN for every signature. This works for any
OpenPGP card, it is not specific to Yubikey.

Yubikey has an additional feature where you can require to physically
touch the Yubikey for each signature. This even protects from malware
using the key in some scenarios where the attacker got the PIN
(keylogger etc.). Not all smartcards/readers have that.

There are also smartcard readers with PIN pad, where the PIN is not
sent to the host in the first place.

It is also possible to forward your gpg-agent via SSH. This way you can
sign large files on a server, but all public-key operations and the PIN
remain on your client.

Regards


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

Re: Validating tarballs against git repositories

[Simon Josefsson]

"G. Branden Robinson"  writes:

> At 2024-03-31T22:32:49+, Stefano Rivera wrote:
>> Upstreams would probably prefer that we used git repositories
>> *directly* as source artifacts, but that comes with a whole other can
>> of worms...
>
> Speaking from my upstream groff perspective, I wouldn't _prefer_ that.
>
> The distribution archives get build-testing on a much wider variety of
> systems, thanks to people on the groff@ and platform-testers@gnu mailing
> lists that help out when a release candidate is announced.  They have
> access to platforms more exotic that I and a few other bleeding-edge
> HEAD mavens do.  This practice tangibly improved the quality of the
> groff 1.23.0 release, especially on surviving proprietary Unix systems.
>
> Building from the repo, or using the bootstrap script--which Colin
> Watson just today ensured will be in future distribution archives--is
> fine.[1]  I'm glad some people build the project that way.  But I think
> that procedure serves an audience that is distinguishable in some ways.

Running ./bootstrap in a tarball may lead to different results than the
maintainer running ./bootstrap in pristine git.  It is the same problem
as running 'autoreconf -fvi' in a tarball does not necessarily lead to
the same result as the maintainer running 'autoreconf -fvi' from
pristine git.  The different is what is pulled in from the system
environment.  Neither tool was designed to be run from within a tarball,
so this is just bad practice that never worked reliable and without a
lot of complexity it will likely not become reliable either.

I have suggested before that upstream's (myself included) should publish
PGP-signed *-src.tar.gz tarballs that contain the entire pristine git
checkout including submodules, *.po translations, and whatever else is
required to actually build the project that is normally pulled in from
external places (autoconf archive macros?).  This *-src.tar.gz tarball
should be possible to ./bootstrap and that would be the intended way to
build it for people who care about vendored files.  Thoughts?  Perhaps I
should formalize this proposal a bit more.

/Simon

> Regards,
> Branden
>
> [1] 
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=822fef56e9ab7cbe69337b045f6f20e32e25f566
>


signature.asc
Description: PGP signature

Re: xz backdoor

[thomas]

On Mar 31, 2024 2:37 PM, Pierre-Elliott Bécue  Wrote:

> The PGP submodule of a Yubikey can host 3 keys, one signing, one 

> authent, and one encrypt. ISTR accessing the signing key is always 

> prompting for the PIN. Same for the encryption key. (I think both can be 

> configured otherwise)


Only for the signing operation, one can turn on the "force-sig" option so that 
the key always prompt for a pin. And that is not the default.


Thomas

Re: Command /usr/bin/mv wrong message in German

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Andrey Rakhmatullin (2024-04-01 09:58:21)
> On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:
> > On 1/4/24 10:18, gregor herrmann wrote:
> > > % dpkg -S $(which mv > coreutils: /usr/bin/mv
> > 
> > On bookworm:
> > 
> > $ dpkg -S $(which mv)
> > dpkg-query: no path found matching pattern /usr/bin/mv
> > 
> > This is caused by the /bin -> /usr/bin shift.
> > 
> > The reason I'm replying is after one, probably two decades this still
> > annoys me:
> > 
> >$ dpkg -S /etc/profile
> >dpkg-query: no path found matching pattern /etc/profile
> > 
> > It was put their by the Debian install, and I'm unlikely to change it.
> > Its fairly important security wise.  It would be nice if "dpkg -S" told
> > me base-files.deb installed it.  It would be nice if debsums told me if
> > it changed.  There are lots of files like this, such as /etc/environment
> > and /etc/hosts.  There are some directories like /etc/apt/trusted.gpg.d/
> > which should only have files claimed by some .deb.
> This is the reason I never expect dpkg -S to work and dpkg -L to be
> correct. The (probably) oldest registered bug report about this is #213907,
> from 2003. RPM has %ghost since before that, of course.

This is the reason I never expect apt-file search to work. It would be nice if
we had a tool which would track the files created by maintainer scripts as well
and associate them to packages. Isn't dumat tracking which files are actually
created after package installation? If yes, can that data be made searchable?

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Command /usr/bin/mv wrong message in German

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:
> On 1/4/24 10:18, gregor herrmann wrote:
> > % dpkg -S $(which mv > coreutils: /usr/bin/mv
> 
> On bookworm:
> 
> $ dpkg -S $(which mv)
> dpkg-query: no path found matching pattern /usr/bin/mv
> 
> This is caused by the /bin -> /usr/bin shift.
> 
> The reason I'm replying is after one, probably two decades this still
> annoys me:
> 
>$ dpkg -S /etc/profile
>dpkg-query: no path found matching pattern /etc/profile
> 
> It was put their by the Debian install, and I'm unlikely to change it.
> Its fairly important security wise.  It would be nice if "dpkg -S" told
> me base-files.deb installed it.  It would be nice if debsums told me if
> it changed.  There are lots of files like this, such as /etc/environment
> and /etc/hosts.  There are some directories like /etc/apt/trusted.gpg.d/
> which should only have files claimed by some .deb.
This is the reason I never expect dpkg -S to work and dpkg -L to be
correct. The (probably) oldest registered bug report about this is
#213907, from 2003.
RPM has %ghost since before that, of course.

-- 
WBR, wRAR


signature.asc
Description: PGP signature