Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel.release > #123571 > unrolled thread

Coordinate response to xz-utils (DSA 5649-1)

Back to article view | Back to linux.debian.devel.release

Contents

  Coordinate response to xz-utils (DSA 5649-1) Ansgar 🙀 <ansgar@43-1.org> - 2024-03-30 00:10 +0100
    Re: Coordinate response to xz-utils (DSA 5649-1) Pierre-Elliott Bécue <peb@debian.org> - 2024-03-30 00:20 +0100
    Re: Coordinate response to xz-utils (DSA 5649-1) Aurelien Jarno <aurel32@debian.org> - 2024-03-30 09:30 +0100
    Re: Coordinate response to xz-utils (DSA 5649-1) Bastian Blank <waldi@debian.org> - 2024-03-30 10:50 +0100
      Re: Coordinate response to xz-utils (DSA 5649-1) Bastian Blank <waldi@debian.org> - 2024-03-30 12:40 +0100

#123571 — Coordinate response to xz-utils (DSA 5649-1)

Hi,

how should we react to the compromised xz-utils upload?

Ubuntu is reverting their amd64 binaries to pre-Feb 25 and rebuilding
stuff.

On Debian side AFAIU currently amd64 buildds are paused and pending
reinstall (plus rotation of key material, both OpenPGP and SSH).

People are starting to investigate packages that have been built since
the compromised xz-utils was uploaded, including packages built for
stable suites using reproducible builds. Is there someone keeping track
of this?

Should we also reset the archive to some prior state and rebuilt
packages like Ubuntu? Do we need to revert to an earlier date as
vulnerable versions have been uploaded to experimental on 2024-02-01
(but the earlier version might only have corrupted test files, not the
payload enabler)? If so, which suites and which architectures? (This
will likely take a while to prepare.)

Do we need any other immediate actions?

Should we use something other than mail to keep track of what we want
to do? (Mail threads can become hard to keep track of after all.)

(Let us please keep future improvements such as more isolated builds
out of this particular discussion.)

Ansgar

[toc] | [next] | [standalone]

#123572

[Multipart message — attachments visible in raw view] — view raw

Ansgar 🙀 <ansgar@43-1.org> wrote on 29/03/2024 at 23:59:38+0100:

> Hi,
>
> how should we react to the compromised xz-utils upload?
>
> Ubuntu is reverting their amd64 binaries to pre-Feb 25 and rebuilding
> stuff.
>
> On Debian side AFAIU currently amd64 buildds are paused and pending
> reinstall (plus rotation of key material, both OpenPGP and SSH).
>
> People are starting to investigate packages that have been built since
> the compromised xz-utils was uploaded, including packages built for
> stable suites using reproducible builds. Is there someone keeping track
> of this?
>
> Should we also reset the archive to some prior state and rebuilt
> packages like Ubuntu? Do we need to revert to an earlier date as
> vulnerable versions have been uploaded to experimental on 2024-02-01
> (but the earlier version might only have corrupted test files, not the
> payload enabler)? If so, which suites and which architectures? (This
> will likely take a while to prepare.)

Considering the payload enabler, I'd focus on amd64 arch and not touch
the archive for anything else.

> Do we need any other immediate actions?
>
> Should we use something other than mail to keep track of what we want
> to do? (Mail threads can become hard to keep track of after all.)

Not sure, but RT could serve this purpose I guess. Or, alternatively, a
(reasonably private) pad.

> (Let us please keep future improvements such as more isolated builds
> out of this particular discussion.)

-- 
PEB

[toc] | [prev] | [next] | [standalone]

#123574

Hi,

On 2024-03-29 23:59, Ansgar 🙀 wrote:
> Hi,
> 
> how should we react to the compromised xz-utils upload?
> 
> Ubuntu is reverting their amd64 binaries to pre-Feb 25 and rebuilding
> stuff.
> 
> On Debian side AFAIU currently amd64 buildds are paused and pending
> reinstall (plus rotation of key material, both OpenPGP and SSH).

All the 8 existing VMs at csail, conova, grnet and ubc have been
shutdown, and their GPG key have been removed on the dak side. Their SSH
key is managed by puppet, so are still enabled at this time, but their
restricted command has been disabled as they are not allowed to build
any architecture.

2 new VMs have been created, x86-grnet-03 and x86-grnet-04. Currently
they only build buster, bullseye and bookworm and the associated
security suites. I didn't enable backports, as it probably needs to be
audited for the builds after Feb 25, like it was done for the security
suites using reproducible builds.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

[toc] | [prev] | [next] | [standalone]

#123578

On Fri, Mar 29, 2024 at 11:59:38PM +0100, Ansgar 🙀 wrote:
> Should we also reset the archive to some prior state and rebuilt
> packages like Ubuntu? Do we need to revert to an earlier date as
> vulnerable versions have been uploaded to experimental on 2024-02-01
> (but the earlier version might only have corrupted test files, not the
> payload enabler)? If so, which suites and which architectures? (This
> will likely take a while to prepare.)

It all depends if we trust the current state of the archive.  If we do
not, we need to revert.  At least with:
- revert xz-utils to binaries from stable
- remove binaries built since the library reached the buildd chroots
- hope that the remaining ones are still enough to have a running debian
- rebuild the lost packages

Do we have evidence that < 5.6.0 actually contained something?  I only
saw changes on something like 2024-02-24 with the added files.

Only amd64 is affected from what was reported.

> Should we use something other than mail to keep track of what we want
> to do? (Mail threads can become hard to keep track of after all.)

We have a suite with some project management capabilities: salsa.  Let's
just use it instead of ad-hoc tools.  I don't think we have something
better right now?

Let's just create a project, for now in the ftp-team group.  It can be
public, because single issues (tasks) can be confidential if needed.
Add security and release team as Reporter, so they can see and modify
everything issue related.

Bastian

-- 
Hailing frequencies open, Captain.

[toc] | [prev] | [next] | [standalone]

#123583

On Sat, Mar 30, 2024 at 10:28:04AM +0100, Bastian Blank wrote:
> We have a suite with some project management capabilities: salsa.  Let's
> just use it instead of ad-hoc tools.  I don't think we have something
> better right now?

This is now https://salsa.debian.org/ftp-team/xz-2024-incident/

Bastian

-- 
Change is the essential process of all existence.
		-- Spock, "Let That Be Your Last Battlefield", stardate 5730.2

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel.release

csiph-web