Re: Validating tarballs against git repositories

On 30/03/24 01:21, Antonio Russo wrote: 3. Have tooling that automatically checks the sanitized sources against the development RCSs. git-buildpackage and pristine-tar can be used for that. 4. Look unfavorably on upstreams without RCS. And look unfavorably on Debian packages without

Accepted satpy 0.47.0-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 07:48:15 + Source: satpy Architecture: source Version: 0.47.0-2 Distribution: unstable Urgency: medium Maintainer: Debian GIS Project Changed-By: Antonio Valentino Closes: 1068007 Changes: satpy (0.47.0-2)

Accepted memcached 1.6.26-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 30 Mar 2024 09:10:43 + Source: memcached Built-For-Profiles: nocheck Architecture: source Version: 1.6.26-1 Distribution: unstable Urgency: medium Maintainer: Chris Lamb Changed-By: Chris Lamb Changes: memcached

Accepted wlogout 1.2.1-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 23 Mar 2024 17:03:04 +0100 Source: wlogout Architecture: source Version: 1.2.1-1 Distribution: unstable Urgency: medium Maintainer: Birger Schacht Changed-By: Birger Schacht Changes: wlogout (1.2.1-1) unstable;

Accepted r-cran-qgraph 1.9.8-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 11:07:03 +0100 Source: r-cran-qgraph Architecture: source Version: 1.9.8-2 Distribution: unstable Urgency: medium Maintainer: Debian R Packages Maintainers Changed-By: Joost van Baal Changes: r-cran-qgraph

Re: Validating tarballs against git repositories

Hello, On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote: > Relying on signed git tags is not reliable because git is primarily > SHA1-based which in 2019 cost $45K to do a collission attack for. We did some analysis on the SHA1 vulnerabilities and determined that they did not

Accepted sphinx-testing 1.0.1-0.3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 13:06:48 +0100 Source: sphinx-testing Architecture: source Version: 1.0.1-0.3 Distribution: unstable Urgency: medium Maintainer: Kouhei Maeda Changed-By: Alexandre Detiste Changes: sphinx-testing (1.0.1-0.3)

Re: Validating tarballs against git repositories

On Sat, Mar 30, 2024 at 01:30:07PM +0100, Jan-Benedict Glaw wrote: > On Sat, 2024-03-30 08:02:04 +0100, Gioele Barabucci wrote: > > On 30/03/24 01:21, Antonio Russo wrote: > > > 3. Have tooling that automatically checks the sanitized sources against > > > the development RCSs. > >

Re: Validating tarballs against git repositories

Hi Sean On 2024/03/30 12:43, Sean Whitton wrote: On 2024-03-30 08:02:04, Gioele Barabucci wrote: Now it is time to take a step forward: 1. new upstream release; 2. the DD/DM merges the upstream release VCS into the Debian VCS; 3. the buildd is notified of the new release; 4. the buildd

Re: Validating tarballs against git repositories

On 29/03/24 at 23:29 -0700, Russ Allbery wrote: > The sad irony here is that the xz maintainer tried to do exactly what we > advise people in this situation to do: try to add a comaintainer to share > the work, and don't block work because you don't have time to personally > vet everything in

Re: xz backdoor

On Sat, Mar 30, 2024, at 05:49, Jonathan Carter wrote: > Another big question for me is whether I should really still > package/upload/etc from an unstable machine. It seems that it may be I have been using stable or old stable + pbuilder for this. Test runs of the results might need a VM

Re: Validating tarballs against git repositories

On Sat, 30 Mar 2024 at 09:57, Iustin Pop wrote: > > On 2024-03-30 08:02:04, Gioele Barabucci wrote: > > Now it is time to take a step forward: > > > > 1. new upstream release; > > 2. the DD/DM merges the upstream release VCS into the Debian VCS; > > 3. the buildd is notified of the new release; >

Accepted cockpit-machines 310-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 12:31:43 +0100 Source: cockpit-machines Architecture: source Version: 310-1 Distribution: unstable Urgency: medium Maintainer: Utopia Maintenance Team Changed-By: Martin Pitt Changes: cockpit-machines (310-1)

Accepted cockpit 314-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 12:25:09 +0100 Source: cockpit Architecture: source Version: 314-1 Distribution: unstable Urgency: medium Maintainer: Utopia Maintenance Team Changed-By: Martin Pitt Changes: cockpit (314-1) unstable;

Re: Validating tarballs against git repositories

On 2024/03/30 11:05, Simon Josefsson wrote: 1. Move towards allowing, and then favoring, git-tags over source tarballs > Some people have suggested this before -- and I have considered adopting that approach myself, but one thing that is often overlooked is that building from git usually

Re: Validating tarballs against git repositories

Am 30.03.2024 um 08:56 schrieb Lucas Nussbaum : > Yes. In that specific case, the original xz maintainer (Lasse Collin) > was socially-pressed by a likely fake person (Jigar Kumar) to do the > "right thing" and hand over maintenance. >

Accepted node-node-sass 7.0.3+git20221109.ee13eb9+dfsg-4 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 13:35:38 +0400 Source: node-node-sass Built-For-Profiles: nocheck Architecture: source Version: 7.0.3+git20221109.ee13eb9+dfsg-4 Distribution: unstable Urgency: medium Maintainer: Debian Javascript Maintainers

Re: xz backdoor

Jonathan Carter wrote on 30/03/2024 at 09:49:33+0100: > Hi Russ > > On 2024/03/29 23:38, Russ Allbery wrote: >> I think the big open question we need to ask now is what exactly the >> backdoor (or, rather, backdoors; we know there were at least two versions >> over time) did. > > Another big

Re: Validating tarballs against git repositories

Hi! On Fri, 2024-03-29 at 23:53:20 -0600, Antonio Russo wrote: > On 2024-03-29 22:41, Guillem Jover wrote: > > On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote: > >> Had tooling existed in Debian to automatically validate this faithful > >> reproduction, we might not have been exposed to

Re: Validating tarballs against git repositories

Antonio Russo writes: > The way I see it, there are two options in handling a buildable package: > 1. That file would have been considered a build artifact, consequently > removed and then regenerated. No backdoor. > 2. The file would not have been scrubbed, and a difference between the > git

Accepted global 6.6.12-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 06:51:14 + Source: global Architecture: source Version: 6.6.12-1 Distribution: unstable Urgency: medium Maintainer: Punit Agrawal Changed-By: Punit Agrawal Changes: global (6.6.12-1) unstable; urgency=medium

Re: Validating tarballs against git repositories

On Sat, Mar 30, 2024 at 09:58:22AM +0100, Ingo Jürgensmann wrote: > > Yes. In that specific case, the original xz maintainer (Lasse Collin) > > was socially-pressed by a likely fake person (Jigar Kumar) to do the > > "right thing" and hand over maintenance. > >

Re: Validating tarballs against git repositories

On Sat, 2024-03-30 08:02:04 +0100, Gioele Barabucci wrote: > On 30/03/24 01:21, Antonio Russo wrote: > > 3. Have tooling that automatically checks the sanitized sources against > > the development RCSs. > > git-buildpackage and pristine-tar can be used for that. Would be nice if

Bug#1068094: RFH: sbcl -- Common Lisp compiler and development system

Package: wnpp Severity: normal X-Debbugs-Cc: s...@packages.debian.org, debian-devel@lists.debian.org, debian-emac...@lists.debian.org Control: affects -1 + src:sbcl I request assistance with maintaining SBCL in Debian. It is the most popular Free Software compiler for Common Lisp. So, most

Accepted digikam 4:8.3.0-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 30 Mar 2024 00:33:58 -0500 Source: digikam Architecture: source Version: 4:8.3.0-2 Distribution: unstable Urgency: medium Maintainer: Debian KDE Extras Team Changed-By: Steve M. Robbins Changes: digikam (4:8.3.0-2)

Re: Validating tarballs against git repositories

On Fri, 2024-03-29 23:53:20 -0600, Antonio Russo wrote: > On 2024-03-29 22:41, Guillem Jover wrote: >> See for example . > > I take a look at these every year or so to keep me terrified of C! > If it's a single upstream developer, I absolutely

Re: Validating tarballs against git repositories

Antonio Russo writes: > 1. Move towards allowing, and then favoring, git-tags over source tarballs Some people have suggested this before -- and I have considered adopting that approach myself, but one thing that is often overlooked is that building from git usually increase the Build-Depends

Accepted signify-openbsd 32-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 10:56:56 +0100 Source: signify-openbsd Architecture: source Version: 32-1 Distribution: unstable Urgency: medium Maintainer: Tomasz Buchert Changed-By: Tomasz Buchert Closes: 1022121 Changes: signify-openbsd

Re: Validating tarballs against git repositories

Hello, On Sat 30 Mar 2024 at 10:56am +01, Iustin Pop wrote: > On 2024-03-30 08:02:04, Gioele Barabucci wrote: >> Now it is time to take a step forward: >> >> 1. new upstream release; >> 2. the DD/DM merges the upstream release VCS into the Debian VCS; >> 3. the buildd is notified of the new

Accepted llvm-defaults 0.58.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 11:27:13 +0100 Source: llvm-defaults Built-For-Profiles: noudeb Architecture: source Version: 0.58.1 Distribution: unstable Urgency: medium Maintainer: LLVM Packaging Team Changed-By: Matthias Klose Changes:

Accepted libreoffice 4:24.2.2-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 09:30:30 + Source: libreoffice Architecture: source Version: 4:24.2.2-2 Distribution: unstable Urgency: medium Maintainer: Debian LibreOffice Maintainers Changed-By: Rene Engelhard Changes: libreoffice

Bug#1068093: ITP: python-cotengrust -- Fast contraction ordering primitives for tensor networks

Package: wnpp Severity: wishlist Owner: Yogeswaran Umasankar X-Debbugs-Cc: debian-devel@lists.debian.org, kd8...@gmail.com * Package name: python-cotengrust Version : 0.1.1 Upstream Contact: Johnnie Gray * URL : https://github.com/jcmgray/cotengrust * License

Accepted linuxptp 4.2-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 07:11:06 + Source: linuxptp Architecture: source Version: 4.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: Punit Agrawal Changes: linuxptp (4.2-1) unstable;

Accepted scalapack 2.2.1-3.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 11:47:52 +0500 Source: scalapack Built-For-Profiles: nocheck Architecture: source Version: 2.2.1-3.1 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Andrey Rakhmatullin

Re: xz backdoor

Hi Russ On 2024/03/29 23:38, Russ Allbery wrote: I think the big open question we need to ask now is what exactly the backdoor (or, rather, backdoors; we know there were at least two versions over time) did. Another big question for me is whether I should really still package/upload/etc from

Accepted gnome-shell-extension-dash-to-panel 60-1~exp2 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 10:24:01 +0200 Source: gnome-shell-extension-dash-to-panel Architecture: source Version: 60-1~exp2 Distribution: experimental Urgency: medium Maintainer: Jonathan Carter Changed-By: Jonathan Carter Changes:

Accepted nacl 20110221-14 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 09:17:37 +0100 Source: nacl Architecture: source Version: 20110221-14 Distribution: unstable Urgency: medium Maintainer: Jan Mojžíš Changed-By: Jan Mojžíš Closes: 1066444 Changes: nacl (20110221-14) unstable;

Re: Validating tarballs against git repositories

On 2024-03-30 08:02:04, Gioele Barabucci wrote: > Now it is time to take a step forward: > > 1. new upstream release; > 2. the DD/DM merges the upstream release VCS into the Debian VCS; > 3. the buildd is notified of the new release; > 4. the buildd creates and uploads the

Re: Validating tarballs against git repositories

Hello, On Fri 29 Mar 2024 at 06:21pm -06, Antonio Russo wrote: > 1. Move towards allowing, and then favoring, git-tags over source tarballs Many of us already do this. dgit maintains an official store of the tags. -- Sean Whitton

Re: Validating tarballs against git repositories

On Sat, 30 Mar 2024 at 06:29, Russ Allbery wrote: > > Antonio Russo writes: > > > The way I see it, there are two options in handling a buildable package: > > > 1. That file would have been considered a build artifact, consequently > > removed and then regenerated. No backdoor. > > > 2. The

Re: Validating tarballs against git repositories

Sean Whitton writes: > Hello, > > On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote: > >> Relying on signed git tags is not reliable because git is primarily >> SHA1-based which in 2019 cost $45K to do a collission attack for. > > We did some analysis on the SHA1 vulnerabilities and

Accepted golang-github-go-git-go-billy 5.5.0-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 29 Mar 2024 20:16:20 +0100 Source: golang-github-go-git-go-billy Architecture: source Version: 5.5.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Simon Josefsson Changes:

Re: Validating tarballs against git repositories

On 30/03/24 10:05, Simon Josefsson wrote: Antonio Russo writes: 1. Move towards allowing, and then favoring, git-tags over source tarballs Some people have suggested this before -- and I have considered adopting that approach myself, but one thing that is often overlooked is that building

Re: Validating tarballs against git repositories

Gioele Barabucci writes: > Just as an example, bootstrapping coreutils currently requires > bootstrapping at least 68 other packages, including libx11-6 [1]. If > coreutils supported [2], the transitive closure of its > Build-Depends would be reduced to 20 packages, most of which in >

Accepted llvm-defaults 0.59~exp2 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 30 Mar 2024 12:19:55 +0100 Source: llvm-defaults Built-For-Profiles: noudeb Architecture: source Version: 0.59~exp2 Distribution: experimental Urgency: medium Maintainer: LLVM Packaging Team Changed-By: Gianfranco Costamagna

Accepted daemontools 1:0.76-10 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 11:50:59 +0100 Source: daemontools Architecture: source Version: 1:0.76-10 Distribution: unstable Urgency: medium Maintainer: Joost van Baal-Ilić Changed-By: Jan Mojžíš Closes: 1066623 Changes: daemontools

Accepted cockpit-podman 86-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 12:29:42 +0100 Source: cockpit-podman Architecture: source Version: 86-1 Distribution: unstable Urgency: medium Maintainer: Martin Pitt Changed-By: Martin Pitt Changes: cockpit-podman (86-1) unstable;

Re: Validating tarballs against git repositories

At 2024-03-30T14:38:03+0200, Jonathan Carter wrote: > On 2024/03/30 11:05, Simon Josefsson wrote: > > > 1. Move towards allowing, and then favoring, git-tags over source tarballs > > > > Some people have suggested this before -- and I have considered > > adopting that approach myself, but one

Accepted libhugetlbfs 2.24-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 07:47:00 + Source: libhugetlbfs Architecture: source Version: 2.24-1 Distribution: unstable Urgency: medium Maintainer: Punit Agrawal Changed-By: Punit Agrawal Closes: 1065601 Changes: libhugetlbfs (2.24-1)

Accepted haskell-haskell-gi 0.26.7-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 30 Mar 2024 08:10:33 +0100 Source: haskell-haskell-gi Built-For-Profiles: noudeb Architecture: source Version: 0.26.7-3 Distribution: unstable Urgency: medium Maintainer: Debian Haskell Group Changed-By: Gianfranco

Accepted libkysdk-base 2.2.0.1-1.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 12:44:02 +0500 Source: libkysdk-base Architecture: source Version: 2.2.0.1-1.1 Distribution: unstable Urgency: medium Maintainer: kylin Team Changed-By: Andrey Rakhmatullin Closes: 1066656 Changes: libkysdk-base

Accepted qtdeclarative-opensource-src-gles 5.15.10+dfsg-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 11:21:30 +0300 Source: qtdeclarative-opensource-src-gles Architecture: source Version: 5.15.10+dfsg-3 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Dmitry Shachnev

Accepted firehol 3.1.7+ds-4 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 30 Mar 2024 08:51:21 + Source: firehol Architecture: source Version: 3.1.7+ds-4 Distribution: unstable Urgency: medium Maintainer: Jerome Benoit Changed-By: Jerome Benoit Closes: 1068046 Changes: firehol (3.1.7+ds-4)

Re: Validating tarballs against git repositories

There are many important and useful things here, but I want to address this one point: On 2024-03-30 00:29, Russ Allbery wrote: > Antonio Russo writes: > >> If that's the case, could make those files at packaging time, analogous >> to the DFSG-exclude stripping process? > > If I have followed

Re: Validating tarballs against git repositories

On 30/03/24 14:08, Jonathan Carter wrote: On 2024/03/30 12:43, Sean Whitton wrote: On 2024-03-30 08:02:04, Gioele Barabucci wrote: Now it is time to take a step forward: 1. new upstream release; 2. the DD/DM merges the upstream release VCS into the Debian VCS; 3. the buildd is notified of the

Re: Validating tarballs against git repositories

Jonathan Carter writes: > On 2024/03/30 11:05, Simon Josefsson wrote: >>> 1. Move towards allowing, and then favoring, git-tags over source tarballs >> >> Some people have suggested this before -- and I have considered adopting >> that approach myself, but one thing that is often overlooked is

Re: xz backdoor

On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote: > I have seen discussion about shifting away from the whole auto(re)conf > tooling to CMake or Meson with there being a reasonable drawback to CMake. > Is that something being discussed within Debian as well? It's not in general something

Re: Validating tarballs against git repositories

On Fri, Mar 29, 2024 at 11:29:01PM -0700, Russ Allbery wrote: >... > In other words, we should make sure that breaking the specific tactics > *this* attacker used truly make the attacker's life harder, as opposed to > making life harder for Debian packagers while only forcing a one-time, > minor

Re: Validating tarballs against git repositories

Russ Allbery writes: > Simon Josefsson writes: >> Sean Whitton writes: > >>> We did some analysis on the SHA1 vulnerabilities and determined that >>> they did not meaningfully affect dgit & tag2upload's design. > >> Can you share that analysis? As far as I understand, it is possible for >> a

Re: xz backdoor

On Sun, Mar 31, 2024 at 04:14:13AM +0300, Adrian Bunk wrote: > The timing of the 5.6.0 release might have been to make it into the > upcoming Ubuntu LTS, it didn't miss it by much. It didn't miss it at all, even. Ubuntu has rolled it back and is rebuilding everything that was built using it,

Re: Validating tarballs against git repositories

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

Re: xz backdoor

On Mar 30, Jonathan Carter wrote: > Another big question for me is whether I should really still > package/upload/etc from an unstable machine. It seems that it may be prudent If we do not use unstable for development then who is going to? I think that the real question is whether we should

Re: xz backdoor

On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote: > Another big question for me is whether I should really still > package/upload/etc from an unstable machine. It seems that it may be prudent > to consider it best practice to work from stable machines where any private > keys are

Re: Validating tarballs against git repositories

On 2024-03-30 11:47:56, Luca Boccassi wrote: > On Sat, 30 Mar 2024 at 09:57, Iustin Pop wrote: > > > > On 2024-03-30 08:02:04, Gioele Barabucci wrote: > > > Now it is time to take a step forward: > > > > > > 1. new upstream release; > > > 2. the DD/DM merges the upstream release VCS into the

Bug#1068108: ITP: python-pysocks -- Python SOCKS client module

Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-pysocks Version : 1.7.1 Upstream Contact: Anorov * URL : https://github.com/Anorov/PySocks * License

Re: Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)

Hi Otto, At 2024-03-30T14:09:46-0700, Otto Kekäläinen wrote: > While reviewing xz-utils commits I noticed that a bunch of old > copyright holder names were removed in > https://salsa.debian.org/debian/xz-utils/-/commit/d1b67558cbc06c449a0ae7b7c1694e277aef4a78. > > Is this OK to do so? My

Some t64 libraries already in testing; I'm confused

My very limited understanding of this major transition was that the t64 libraries are being held in unstable until (almost) everything is ready, at which point there will be a coordinated migration into testing. But I've now been asked to upgrade something on my testing machine which pulls in a

Re: xz backdoor

De : Adrian Bunk À : Pierre-Elliott Bécue Cc : debian-devel@lists.debian.org Date : 31 mars 2024 00:25:09 Objet : Re: xz backdoor > On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote: >> ... >> I'd be happy to have Debian France care about buying and having yubikeys >>

Re: xz backdoor

Hi! On Sat, 30 Mar 2024 at 14:32, Andrey Rakhmatullin wrote: > On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote: > > Another big question for me is whether I should really still > > package/upload/etc from an unstable machine. It seems that it may be prudent > > to consider it

Re: Validating tarballs against git repositories

On Fri, Mar 29, 2024 at 06:21:27PM -0600, Antonio Russo wrote: >... > 1. Move towards allowing, and then favoring, git-tags over source tarballs >... git commit IDs, not tags. Upstream moving git tags does sometimes happen. Usually for bad-but-not-malicious reasons like "add one more

Re: xz backdoor

Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri escreveu: >On Mar 30, Jonathan Carter wrote: > >> Another big question for me is whether I should really still >> package/upload/etc from an unstable machine. It seems that it may be prudent >If we do not use unstable for development

Re: xz backdoor

Santiago Ruano Rincón wrote on 30/03/2024 at 22:59:43+0100: > Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri > escreveu: >>On Mar 30, Jonathan Carter wrote: >> >>> Another big question for me is whether I should really still >>> package/upload/etc from an unstable machine. It seems

Re: xz backdoor

On Sun, Mar 31, 2024 at 01:20:39AM +0200, Adrian Bunk wrote: > On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote: > >... > > I'd be happy to have Debian France care about buying and having yubikeys > > delivered to any DD over the world. > > Including Russia? > Supporting DDs

Re: Validating tarballs against git repositories

On 2024-03-29 23:29:01 -0700 (-0700), Russ Allbery wrote: [...] > if the Git repository is somewhere other than GitHub, the > malicious possibilities are even broader. [...] I would not be so quick to make the same leap of faith. GitHub is not itself open source, nor is it transparently operated.

Re: xz backdoor

Hi, On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote: > On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote: > > > I think that the real question is whether we should really still > > use > > code-signing keys which are not stored in (some kind of) HSM. > What are the

Re: Validating tarballs against git repositories

On 2024-03-31 00:58:49, Andrey Rakhmatullin wrote: > On Sat, Mar 30, 2024 at 10:56:40AM +0100, Iustin Pop wrote: > > > Now it is time to take a step forward: > > > > > > 1. new upstream release; > > > 2. the DD/DM merges the upstream release VCS into the Debian VCS; > > > 3. the buildd is

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

Hi Diane, On Fri, Mar 29, 2024 at 11:49:07AM -0700, Diane Trout wrote: > On Mon, 2024-03-25 at 18:17 +, Julian Gilbey wrote: > > > > > > So this is a plea for anyone looking for something really helpful to > > do: it would be great to have a group of developers finally package > > this! 

Re: xz backdoor

On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote: >... > I'd be happy to have Debian France care about buying and having yubikeys > delivered to any DD over the world. Including Russia? cu Adrian

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

Hi Julian, On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote: > Lovely to hear from you, and oh wow, that's amazing, thank you! > > I can't speak for anyone else, but I suggest that pushing your > updates > to the science-team package would be very sensible; it would be silly > for someone

Re: xz backdoor

On Sat, Mar 30, 2024 at 08:52:29PM +0100, Ansgar  wrote: > Hi, > > On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote: > > On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote: > > > > > I think that the real question is whether we should really still > > > use > > >

Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)

Hi! While reviewing xz-utils commits I noticed that a bunch of old copyright holder names were removed in https://salsa.debian.org/debian/xz-utils/-/commit/d1b67558cbc06c449a0ae7b7c1694e277aef4a78. Is this OK to do so? Having source code in the public domain means that there is no copyright, so

Re: xz backdoor

On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote: >... > On 2024/03/29 23:38, Russ Allbery wrote: > > I think the big open question we need to ask now is what exactly the > > backdoor (or, rather, backdoors; we know there were at least two versions > > over time) did. > > Another

Re: xz backdoor

El 31/03/24 a las 00:53, Christian Kastner escribió: > On 2024-03-30 22:59, Santiago Ruano Rincón wrote: > > The backdoor was discovered by someone using the compromised xz-utils *in > > their own machines*. So we are lucky we have people eating our own sid > > stuff before it becomes part of a

Re: Validating tarballs against git repositories

On Sat, 30 Mar 2024 at 10:16, Guillem Jover wrote: [snip] This: > I'm personally not a fan of pristine-tar, and my impression is that it > is falling out of favor in various corners and big teams within the > project. And then I'm also not a fan either for mixing packaging with > upstream git

Re: xz backdoor

On 2024-03-30 17:00, Marco d'Itri wrote: > On Mar 30, Jonathan Carter wrote: > >> Another big question for me is whether I should really still >> package/upload/etc from an unstable machine. It seems that it may be prudent > If we do not use unstable for development then who is going to? Are

Re: xz backdoor

On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote: > On Mar 30, Jonathan Carter wrote: > > > Another big question for me is whether I should really still > > package/upload/etc from an unstable machine. It seems that it may be prudent > If we do not use unstable for development then

Re: Validating tarballs against git repositories

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

Re: xz backdoor

Sirius (2024-03-30): > I have seen discussion about shifting away from the whole auto(re)conf > tooling to CMake or Meson with there being a reasonable drawback to > CMake. Is that something being discussed within Debian as well? Talking about alternatives to autotools:

Re: xz backdoor

Hi, On Sat, Mar 30, 2024 at 7:00 PM Santiago Ruano Rincón wrote: > > > > Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri > escreveu: > >On Mar 30, Jonathan Carter wrote: > > > >> Another big question for me is whether I should really still > >> package/upload/etc from an unstable

Re: Validating tarballs against git repositories

Simon Josefsson writes: > Russ Allbery writes: >> I believe you're talking about two different things. I think Sean is >> talking about preimage resistance, which assumes that the known-good >> repository is trusted, and I believe Simon is talking about >> manufactured collisions where the

Re: xz backdoor

On 2024-03-30 20:52 +0100, Ansgar  wrote: > Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices. > Possibly also TPM modules in computers. > > These can usually be used for both OpenPGP and SSH keys. Slightly off-topic, but a couple of recent posts have given me the same thought:

Re: xz backdoor

On Sun, 2024-03-31 at 03:34 +0100, Wookey wrote: > On 2024-03-30 20:52 +0100, Ansgar  wrote: > > Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices. > > Possibly also TPM modules in computers. > > > > These can usually be used for both OpenPGP and SSH keys. > > Slightly

Re: Some t64 libraries already in testing; I'm confused

On 2024-03-30 Julian Gilbey wrote: > My very limited understanding of this major transition was that the > t64 libraries are being held in unstable until (almost) everything is > ready, at which point there will be a coordinated migration into > testing. But I've now been asked to upgrade

Git and SHA1 collisions (Was: Re: Validating tarballs against git repositories)

On 30/03/24 23:09, Simon Josefsson wrote: Russ Allbery writes: Simon Josefsson writes: Sean Whitton writes: We did some analysis on the SHA1 vulnerabilities and determined that they did not meaningfully affect dgit & tag2upload's design. Can you share that analysis? As far as I

Re: Validating tarballs against git repositories

On 30/03/24 13:38, Jonathan Carter wrote: On 2024/03/30 11:05, Simon Josefsson wrote: 1. Move towards allowing, and then favoring, git-tags over source tarballs > Some people have suggested this before -- and I have considered adopting that approach myself, but one thing that is often

Re: Validating tarballs against git repositories

Ingo Jürgensmann writes: > This reminds me of https://xkcd.com/2347/ - and I think that’s getting a > more common threat vector for FLOSS: pick up some random lib that is > widely used, insert some malicious code and have fun. Then also imagine > stuff that automates builds in other ways like

Re: Validating tarballs against git repositories

Simon Josefsson writes: > Sean Whitton writes: >> We did some analysis on the SHA1 vulnerabilities and determined that >> they did not meaningfully affect dgit & tag2upload's design. > Can you share that analysis? As far as I understand, it is possible for > a malicious actor to create a git

Re: Validating tarballs against git repositories

Jeremy Stanley writes: > On 2024-03-29 23:29:01 -0700 (-0700), Russ Allbery wrote: > [...] >> if the Git repository is somewhere other than GitHub, the >> malicious possibilities are even broader. > [...] > I would not be so quick to make the same leap of faith. GitHub is > not itself open

Re: xz backdoor

In days of yore (Fri, 29 Mar 2024), Russ Allbery thus quoth: > Russ Allbery writes: > > Sirius writes: > > >> 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

Re: xz backdoor

Christian Kastner writes: > This is both out of convenience (I want my workstation to be based on > stable) and precisely because of the afforded isolation. I personally specifically want my workstation to be running unstable, so I'm watching to see if that's considered unsafe (either,

  1   2   >