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 VCS

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 detai

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 a

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

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. > https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.htm

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 qu

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. > > https://www.mail-archive.com/xz-devel

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 non-reviewed-in-practice

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 fr

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

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 relea

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 > build-es

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 tho

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 ques

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

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 file

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 meaningfull

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 pristine-tar

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 increa

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 thing

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

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 creates

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

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

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 anyon

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 determ

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 hi

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 t

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 overloo

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 th

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 perspec

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 doc

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 r

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 reall

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

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 taki

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 source

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 you

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, immediate

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 inv

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 wh

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 Debia

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: 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 option

Re: Validating tarballs against git repositories

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 notified of the new release; > > 4. the buildd creates and uploads the

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 > > > code-sign

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 tha

Re: xz backdoor

On 2024-03-30 20:20, Russ Allbery wrote: > I personally specifically want my workstation to be running unstable, so > I'm watching to see if that's considered unsafe (either, immediately, > today, or in theory, in the future). > > If I have to use a stable host, I admit I will be sad. I've been u

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 notified

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 buil

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!  The

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: https://git.tukaani.or

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 n

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 last-minute

Re: xz backdoor

On Mar 30, Christian Kastner 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 you both talking about unstable h

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 opinion

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 the

Bug#1068113: ITP: libsmb2 -- SMB2/3 client library

ITP: libsmb2 -- SMB2/3 client library Package: wnpp Severity: wishlist Owner: Joe Mondloch X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libsmb2 Version : 4.0.0 Upstream Authors: Ronnie Sahlberg URL : https://github.com/sahlberg/libsmb2 * License

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 m

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 sh

Re: xz backdoor

Ansgar 🙀 wrote on 30/03/2024 at 20:52:29+0100: > 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

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

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 machi

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 t6

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 atta

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: Validating tarballs against git repositories

Hi, * Simon Josefsson [2024-03-30 12:19]: 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. FWIW, Gitlab is working on support for SHA 256 hashing [1], and as of Git 2.42, the SHA 256 repository format has matu

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 i

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

Re: xz backdoor

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 stable release. The luck was that this particular compromise

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 bi

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, but

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 s

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

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 best

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 off-topic,

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 e

Re: xz backdoor

On 2024-03-31 Wookey wrote: [...] > e.g. I remember it took me years to realise that I used _my_ public > key for signing, [...] Good morning, s/public/private/ - $recipient can then use your public key to verify the sig. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other

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 somethi

Re: xz backdoor

Diane Trout wrote: > 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. >>

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 unders

Re: Validating tarballs against git repositories

On 30/03/24 20:43, Iustin Pop wrote: On 2024-03-30 11:47:56, Luca Boccassi wrote: On Sat, 30 Mar 2024 at 09:57, Iustin Pop wrote: Give me good Salsa support for autopkgtest + lintian + piuparts, and easy support (so that I just have to toggle one checkbox), and I'm happy. Or even better, integ

Re: Validating tarballs against git repositories

On 29/03/24 at 23:29 -0700, Russ Allbery wrote: > Antonio Russo writes: > > But, I will definitely concede that, had I seen a commit that changed > > that line in the m4, there's a good chance my eyes would have glazed > > over it. > > This is why I am somewhat skeptical that forcing everything i

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

On 2024-03-31 06:54 +0200, Andreas Metzler wrote: > 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 int