Presumably these commits are taking some upstream release archive and extracting it over main branch of https://salsa.debian.org/debian/xz-utils.git? git log --pretty=format:'%h%x09%an%x09%ad%x09%s' --grep "New upstream version" 2e006444 Sebastian Andrzej Siewior Sun Oct 6 10:46:41 2024 +0200 New upstream version 5.6.3 9c967ee5 Sebastian Andrzej Siewior Thu Jun 13 22:42:29 2024 +0200 New upstream version 5.6.2 f7c276c1 Sebastian Andrzej Siewior Tue Mar 26 21:58:49 2024 +0100 New upstream version 5.6.1 12388833 Sebastian Andrzej Siewior Sat Feb 24 17:59:06 2024 +0100 New upstream version 5.6.0 8f7c58cf Sebastian Andrzej Siewior Thu Feb 15 19:39:38 2024 +0100 New upstream version 5.5.2beta 31593160 Sebastian Andrzej Siewior Wed Jan 31 21:32:47 2024 +0100 New upstream version 5.5.1alpha a9aa9fc2 Sebastian Andrzej Siewior Thu Nov 23 20:31:22 2023 +0100 New upstream version 5.4.5 f9387923 Sebastian Andrzej Siewior Sun Aug 27 18:35:51 2023 +0200 New upstream version 5.4.4 ef7e9141 Sebastian Andrzej Siewior Wed Jan 11 21:51:42 2023 +0100 New upstream version 5.4.1 1d1835f3 Sebastian Andrzej Siewior Tue Dec 13 21:50:15 2022 +0100 New upstream version 5.2.10 b2f4e148 Sebastian Andrzej Siewior Tue Dec 13 21:47:48 2022 +0100 New upstream version 5.4.0 0de83be5 Sebastian Andrzej Siewior Fri Dec 2 22:03:21 2022 +0100 New upstream version 5.3.5beta 07c94c7d Sebastian Andrzej Siewior Fri Dec 2 21:57:44 2022 +0100 New upstream version 5.2.9 d6771448 Sebastian Andrzej Siewior Wed Nov 23 21:14:43 2022 +0100 New upstream version 5.2.8 7ebcc3c7 Sebastian Andrzej Siewior Fri Nov 18 21:31:44 2022 +0100 New upstream version 5.3.4alpha e2535a4f Sebastian Andrzej Siewior Wed Oct 5 22:57:40 2022 +0200 New upstream version 5.2.7 1f39f4fd Sebastian Andrzej Siewior Thu Sep 29 21:41:04 2022 +0200 New upstream version 5.3.3alpha cbc4aecd Sebastian Andrzej Siewior Sun Dec 27 17:37:18 2020 +0100 New upstream version 5.2.5 I note the upstream maintainer is now signing release archives, but we still have to trust whatever process the maintainer used to generate the release. Wouldn't it be more transparent if maintainer's version was 1to1 with upstream except for debian and do autogen in the dh rules if possible? This is probably naive but simply adding this seems to work (at least doesn't fail): override_dh_update_autotools_config: ./autogen.sh It would also make https://salsa.debian.org/debian/xz-utils.git less confusing. I mean if extracting a release archive then committing it the approach to syncing with upstream why does it share large tree of commit history with upstream at all? P.S. I also not 5.2.4 didn't have autogen assets in the maintainer repo, but on the other hand they are in the source package orig.tar.xz somehow - which is probably even less good in terms on transparency.
… This is the import of the orig tarball into git. correct. I plan to switch to cmake at some point. Then we don't have to worry about autoconf magic. How is this different from the current autoreconf step that is already as part of dh? Note that problem back then was that the shipped archived contained m4 files so the autogen step did not "help". gbp does this. I don't know what you want me to do here. Other than adding ./autogen.sh as part of the build process which is already handled. Sebastian
Hi Sebastian. Sounds good. The default update autotools dh rule doesn't seem to work / produce the same result without the autogen assets already present in the package source. I'm simply suggesting using the Github source as the upstream not the Github release tarball. Regards, Sam.
Not effectively, other than being vulnerable to less well-thought-out upstream autogen.sh code. That’s irrelevant (and, in fact, highly desired, since the ones in Debian also patch in e.g. support for new architectures). Furthermore, the attack actually *relied* on doing so. bye, //mirabilos
On Fri, 7 Mar 2025 17:45:29 +0100 (CET) Thorsten Glaser <tg@debian.org> wrote: > >> Note that problem back then was that the shipped archived > >> contained m4 files so the autogen step did not "help". > > the attack actually *relied* on doing so. > Just to clarify what your saying here: the attack relied on smuggling in a .m4 file that was not present in the Github source code but was present in the Github release tarball used as the upstream source for this package.