Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Thanks for the response! On Fri, 5 Apr 2024 11:12:33 +0200, Guillem wrote: > On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote: > > On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote: > > > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > > > > On 2024-03-29 22:41, Guillem Jover

Re: Validating tarballs against git repositories

Hello, On Fri 05 Apr 2024 at 03:19pm +01, Simon McVittie wrote: > There are basically three dgit-compatible workflows, with some minor > adjustments around handling of .gitignore files: > > - "patches applied" (git-debrebase, etc.): > This is the workflow that proponents of dgit sometimes

Re: Validating tarballs against git repositories

On Apr 05, Simon McVittie wrote: > I find that having the upstream source code in git (in the same form that > we use for the .orig.tar.*, so including Autotools noise, etc. if present, > but excluding any files that we exclude by repacking) is an extremely > useful tool, because it lets me

Re: Validating tarballs against git repositories

On Fri, 5 Apr 2024 at 16:18, Colin Watson wrote: > > On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote: > > I find that having the upstream source code in git (in the same form that > > we use for the .orig.tar.*, so including Autotools noise, etc. if present, > > but excluding any

Re: Validating tarballs against git repositories

On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote: > I find that having the upstream source code in git (in the same form that > we use for the .orig.tar.*, so including Autotools noise, etc. if present, > but excluding any files that we exclude by repacking) is an extremely > useful

Re: Validating tarballs against git repositories

On Sat, 30 Mar 2024 at 14:16:21 +0100, Guillem Jover wrote: > in my mind this incident reinforces my view that precisely storing > more upstream stuff in git is the opposite of what we'd want, and > makes reviewing even harder, given that in our context we are on a > permanent fork against

Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Hi! On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote: > On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote: > > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > > > On 2024-03-29 22:41, Guillem Jover wrote: > > > I think with my upstream hat on I'd rather ship a clear manifest

Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Hi Guillem, On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote: > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > > On 2024-03-29 22:41, Guillem Jover wrote: > > I think with my upstream hat on I'd rather ship a clear manifest (checked > > into Git) that tells distributions which files

Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Hi! On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > On 2024-03-29 22:41, Guillem Jover wrote: > > (For dpkg at least I'm pondering whether to play with switching to > > doing something equivalent to «git archive» though, but see above, or > > maybe generate two tarballs, a plain «git

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

Stefano Rivera writes: > Then you haven't come across any that are using this mechanism to > install data, yet. You're only seeing the version determination. You > will, at some point run into this problem. It's getting more popular. Yup, we use this mechanism heavily at work, since it avoids

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

On 3/30/24 08:02, Gioele Barabucci wrote: For too many core packages there is an opaque "something happens on the Debian maintainer laptop" step that has no place in 2024. Let's replace this by an opaque "something happens on the Salsa CI". Cheers, Thomas Goirand (zigo)

Re: Validating tarballs against git repositories

On 4/1/24 00:32, Stefano Rivera wrote: So... for Python packages using setuptools-scm, we're pushed towards depending on upstream-created source tarballs (sdists), rather than upstream git archives, because we don't have the ".git" directory in our source packages. Hi Stefano, Thanks for

Re: Validating tarballs against git repositories

PICCA Frederic-Emmanuel writes: > One missing piece for me in order to migrate to meson is the integration > between flymake and the autotools. > > https://www.emacswiki.org/emacs/FlyMake#h5o-7 > There is an unofficial Meson LSP[1]. Maybe it can be configured with Eglot or lsp-mode. --

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

On Tue, Apr 02, 2024 at 08:20:31PM +0300, Adrian Bunk wrote: > On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote: > > On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote: > > > Does gnulib upstream support upgrading/downgrading the gnulib m4 files > > > (like the one used in the

Re: Validating tarballs against git repositories

On 2024-04-02 11:05, Russ Allbery wrote: Meson honestly sounds great, and I personally love the idea of using a build system whose language is a bit more like Python, since I use that language professionally anyway. (It would be nice if it *was* Python rather than yet another ad hoc language,

Re: Validating tarballs against git repositories

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

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

On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote: > On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote: > > On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote: > > > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote: > > > > This seems like a serious bug in

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

On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote: > On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote: > > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote: > > > This seems like a serious bug in autoreconf, but I've not checked if > > > this has been brought up

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

On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote: >... > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote: >... > > This seems like a serious bug in autoreconf, but I've not checked if > > this has been brought up upstream, and whether they consider it's > > working as

Re: Validating tarballs against git repositories

Adrian Bunk writes: > On Mon, Apr 01, 2024 at 11:17:21AM -0400, Theodore Ts'o wrote: >> Yeah, that too. There are still people building e2fsprogs on AIX, >> Solaris, and other legacy Unix systems, and I'd hate to break them, or >> require a lot of pain for people who are building on MacPorts,

Re: Validating tarballs against git repositories

On Mon, Apr 01, 2024 at 11:17:21AM -0400, Theodore Ts'o wrote: > On Sat, Mar 30, 2024 at 08:44:36AM -0700, Russ Allbery wrote: >... > > Yes, perhaps it's time to switch to a different build system, although one > > of the reasons I've personally been putting this off is that I do a lot of > >

Re: Validating tarballs against git repositories

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

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

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 >

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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,

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

"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

Re: Validating tarballs against git repositories

On Apr 01, gregor herrmann wrote: > > I switched long ago all my packages from tar archives to the git > > upstream tree. Not only this makes much easier to understand the changes > > in a new release, > That's not mutually exclusive. When adding an additional git remote > and using

Re: Validating tarballs against git repositories

On Sun, 31 Mar 2024 23:59:20 +0200, Marco d'Itri wrote: > I switched long ago all my packages from tar archives to the git > upstream tree. Not only this makes much easier to understand the changes > in a new release, That's not mutually exclusive. When adding an additional git remote and

Re: Validating tarballs against git repositories

On Sun, 31 Mar 2024 10:12:35 -0700, Russ Allbery wrote: > > My point is that, while there will be for sure exceptions here and > > there, by and large the need for massaged tarballs comes from projects > > using autoconf and wanting to ship source archives that do not require > > to run the

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

Hi Guillem (2024.03.30_04:41:37_+) > > 1. Move towards allowing, and then favoring, git-tags over source tarballs > > I assume you mean git archives out of git tags? Otherwise how do you > go from git-tag to a source package in your mind? There are some issues with transforming upstream's

Re: Validating tarballs against git repositories

On Mar 31, Russ Allbery wrote: > Most of this is pregenerated documentation (primarily man pages generated > from POD), but it also includes generated test data and other things. The > reason is similar: regenerating those files requires tools that may not be > present on an older system (like

Re: Validating tarballs against git repositories

On Sat, Mar 30, 2024 at 11:55:04AM +, Luca Boccassi wrote: >... > 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

Re: Validating tarballs against git repositories

Luca Boccassi writes: > On Sat, 30 Mar 2024 at 15:44, 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

Re: Validating tarballs against git repositories

On 2024-03-31 08:03:40, Gioele Barabucci wrote: > 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

Re: Validating tarballs against git repositories

On Sat, 30 Mar 2024 at 15:44, 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

Re: Validating tarballs against git repositories

On Sun, Mar 31, 2024 at 08:16:33AM +0200, Lucas Nussbaum wrote: > On 29/03/24 at 23:29 -0700, Russ Allbery wrote: > > This is why I am somewhat skeptical that forcing everything into Git > > commits is as much of a benefit as people are hoping. This particular > > attacker thought it was better

Re: Validating tarballs against git repositories

On 2024-03-30 12:19 +0100, Simon Josefsson wrote: > 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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

Re: Validating tarballs against git repositories

On 2024-03-29 22:41, Guillem Jover wrote: > Hi! > > On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote: >> This is a vector I've been somewhat paranoid about myself, and I >> typically check the difference between git archive $TAG and the downloaded >> tar, whenever I package things.

Re: Validating tarballs against git repositories

Hi! On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote: > This is a vector I've been somewhat paranoid about myself, and I > typically check the difference between git archive $TAG and the downloaded > tar, whenever I package things. Obviously a backdoor could have been > inserted into

Validating tarballs against git repositories

Hello everyone, As I'm sure we're all aware of at this point, Debian has been a victim of a relatively sophisticated first-party attack whereby a backdoor of the XZ package was smuggled into sshd via a systemd dependency. This backdoor, at a minimum, attacked key verification. As far as I