[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
On Mon, 01 Apr 2024 09:53:38 -0400 Michael Richardson wrote: > The entire openwrt thread is at: > https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042499.html > continuing at: > https://lists.openwrt.org/pipermail/openwrt-devel/2024-April/042521.html > > > Daniel Golle wrote: > > However, after reading up about the details of this backdoored > > release tarball, I believe that the current tendency to use > > tarballs rather than (reproducible!) git checkouts is also > > problematic to begin with. > > > Stuff like 'make dist' seems like a weird relic nowadays, > > creates more problems than it could potentially solve, > > bandwidth is ubiquitous, and we already got our own tarball > > mirror of git checkouts done by the buildbots (see > > PKG_MIRROR_HASH). So why not **always** use that instead of > > potentially shady and hard to verify tarballs? > I wonder if we should nuke our own make tarball system. The short answer is "no". Before I go into detail, please try not to take the following comments personally, but to focus on the problem. The problem seems to be a bit bigger than this project, so this in part preemptively addresses arguments you did not make, but other people did in other similar arguments about the same matter. First of all, the root cause is not a technical problem: a widely used software project got compromised, on this occasion a developer was the attack vector. Some people feel more angry or scared about it than usual (this is neither the first nor the last nor the biggest incident of this kind, truth be told) and I sympathise with these temporary emotions. However, I do not sympathise with the widespread urge to demonstrate control over the situation by any means or to vent the frustration right now at... something... anything really, does not matter, whatever happens to be in plain sight right now. Likewise, the proposed move would not be a technical solution, or a solution at all. It would scratch a momentary emotional itch today with no regard to the technical lessons learned yesterday and technical problems to be solved tomorrow. Let's try to apply a bit of critical thinking to the matter: * Speaking of Autoconf imperfections, please note that CMake has been available for several years. That said, CMake project definitions are not immune to being used as a delivery vehicle for an exploit into an open source project. CMake executables are not immune to being compromised. make (whether GNU or not) is not immune. The compiler is not immune. The linker is not immune. The libc is not immune. The OS is not immune. And (now we are getting to the difficult part) neither hardware nor VM hypervisors are immune to being compromised. Let's leave Autoconf in peace, it is not the root cause. * Speaking of imperfections of published signed tarballs, please note that the public git repositories have been available for many years. That said, a git repository is not immune to being used as a delivery vehicle for an exploit into an open source project. Just labelling something with "stored securely in git" does not automatically eliminate the threat. For the avoidance of doubt, git as a piece of software is not immune to being compromised. And online services that host git repositories are not immune either. Considering the problem of getting the source code by some means, the only way to guarantee having the exact actual source code is actually to have the exact actual source code. Which in git parlance means actually having a local git clone that (possibly among many other things) includes the very specific revision of interest, which overshoots the problem space massively. If you look at kernel.org and compare downloading of a tarball of a specific kernel version to cloning a repository (which? how deep?) and identifying the correct tag, the difference should be obvious. These two solutions address two different problems, neither is the root cause and neither is immune to being compromised. To demonstrate the difference between the two solution spaces further, git repositories by design do not store file modification times or permissions other than the executable bit, so in practice two identical, as far as git is concerned, clones tend to be different, as far as "ls -lR" is concerned. Let's leave signed tarballs in peace. There is a valid concern of whether a tarball is a close enough result of "make releasetar" for the respective git tag. Let's not guess, let's prove it. Would anybody like to implement a script that would compare the contents of https://www.tcpdump.org/release/ with the git repositories? * The "all git repositories are already available" argument does not hold, for example, when one starts with a fresh install of NetBSD with just make, cc and a tarball of pkgsrc release. Before you can use git,
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
On Mon, Apr 1, 2024 at 11:06 AM Michael Richardson wrote: > > Bill Fenner wrote: > > mcr suggested: > >> I wonder if we should nuke our own make tarball system. > > > The creation of a tarball and its signature gives a place to hang > one's hat > > about origin of code - "someone with the right key claims that this > tarball > > genuinely reflects what the project wants to distribute". Is there a > > similar mechanism for a git tag? > > Yes, git tag -s, lets you sign a commit with a PGP key. > Just trying to brainstorm about how this fits with build systems like Arista's, where we store the tarball and check the signature at build time - I suppose it just turns into "vendor the git tag into a local repo and check the signature at build time". I have no objection to either requiring people to have autotools, or going cmake-only. (I mean, I personally find cmake hard to use, but that shouldn't influence what the project does.) Bill ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
Guy Harris wrote: > If so, do we > 1) require people to have autotools installed and run ./autogen.sh > or > 2) generate the configure scripts on some standard platform and check it in 3) stop using autoconf, cmake only. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
--- Begin Message ---
On 01/04/2024 20:18, Guy Harris wrote:
> On Apr 1, 2024, at 6:53 AM, Michael Richardson wrote:
>
>> I wonder if we should nuke our own make tarball system.
>
> I.e., replace:
>
> to get {libpcap,tcpdump,tcpslice} version X.Y.Z, download
> {libpcap,tcpdump,tcpslice}-X.Y.Z.tar.{compression-suffix}
>
> with
>
> to get {libpcap,tcpdump,tcpslice} version X.Y.Z, do
>
> git clone {repository}
>
> and then check out Git tag {libpcap,tcpdump,tcpslice}-X.Y.Z?
>
> If so, do we
>
> 1) require people to have autotools installed and run ./autogen.sh
I vote for 1).
--- End Message ---
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
On Apr 1, 2024, at 6:53 AM, Michael Richardson wrote:
> I wonder if we should nuke our own make tarball system.
I.e., replace:
to get {libpcap,tcpdump,tcpslice} version X.Y.Z, download
{libpcap,tcpdump,tcpslice}-X.Y.Z.tar.{compression-suffix}
with
to get {libpcap,tcpdump,tcpslice} version X.Y.Z, do
git clone {repository}
and then check out Git tag {libpcap,tcpdump,tcpslice}-X.Y.Z?
If so, do we
1) require people to have autotools installed and run ./autogen.sh
or
2) generate the configure scripts on some standard platform and check
it in
so that they have a configure script? Or is there some other way to arrange
that people can get the configure scripts?
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
Bill Fenner wrote: > mcr suggested: >> I wonder if we should nuke our own make tarball system. > The creation of a tarball and its signature gives a place to hang one's hat > about origin of code - "someone with the right key claims that this tarball > genuinely reflects what the project wants to distribute". Is there a > similar mechanism for a git tag? Yes, git tag -s, lets you sign a commit with a PGP key. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)
mcr suggested: > I wonder if we should nuke our own make tarball system. The creation of a tarball and its signature gives a place to hang one's hat about origin of code - "someone with the right key claims that this tarball genuinely reflects what the project wants to distribute". Is there a similar mechanism for a git tag? Bill ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] openwrt Conclusions from CVE-2024-3094 (libxz disaster)
The entire openwrt thread is at: https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042499.html continuing at: https://lists.openwrt.org/pipermail/openwrt-devel/2024-April/042521.html Daniel Golle wrote: > However, after reading up about the details of this backdoored release > tarball, I believe that the current tendency to use tarballs rather > than (reproducible!) git checkouts is also problematic to begin with. > Stuff like 'make dist' seems like a weird relic nowadays, creates more > problems than it could potentially solve, bandwidth is ubiquitous, and > we already got our own tarball mirror of git checkouts done by the > buildbots (see PKG_MIRROR_HASH). So why not **always** use that > instead of potentially shady and hard to verify tarballs? I wonder if we should nuke our own make tarball system. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
