From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Trent W. Buck" Newsgroups: gmane.emacs.bugs Subject: bug#52477: 27.1; .crx and .crx3 are zip files Date: Thu, 23 Dec 2021 15:01:20 +1100 Message-ID: References: <878rwn238l.fsf@gmail.com> <87lf0l53mu.fsf@gmx.de> <83r1achpkv.fsf@gnu.org> <874k78hibe.fsf@gmx.de> <83fsqshehh.fsf@gnu.org> <87ee64esqt.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29327"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefan@marxist.se, 52477@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 23 05:02:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n0FIx-0007Uj-60 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Dec 2021 05:02:11 +0100 Original-Received: from localhost ([::1]:56740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n0FIv-00084s-J9 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Dec 2021 23:02:09 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55304) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0FIo-00084Y-7T for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 23:02:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48622) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n0FIn-0006X5-Tu for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 23:02:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n0FIn-0000Mi-Ok for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 23:02:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Trent W. Buck" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Dec 2021 04:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52477 X-GNU-PR-Package: emacs Original-Received: via spool by 52477-submit@debbugs.gnu.org id=B52477.16402320951369 (code B ref 52477); Thu, 23 Dec 2021 04:02:01 +0000 Original-Received: (at 52477) by debbugs.gnu.org; 23 Dec 2021 04:01:35 +0000 Original-Received: from localhost ([127.0.0.1]:60168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0FIM-0000M1-PX for submit@debbugs.gnu.org; Wed, 22 Dec 2021 23:01:35 -0500 Original-Received: from mail-pg1-f179.google.com ([209.85.215.179]:41589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0FIK-0000Lo-Su for 52477@debbugs.gnu.org; Wed, 22 Dec 2021 23:01:33 -0500 Original-Received: by mail-pg1-f179.google.com with SMTP id k4so3786309pgb.8 for <52477@debbugs.gnu.org>; Wed, 22 Dec 2021 20:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=+GX1IQDOxwUTPUe8Y5UJUWujZNd0dHuTLCJsq+WBnTg=; b=CzbDQQxJGU/FNYY7wQtTcZExnYWX9gS1etamqwgh4Alq35RiVQxfijBMrHz9TKtknU 0ebI3xIweQJbq5+7+7FjLr0o0o1reAuto3ThbQ4vaMriTYV6iWyDi/75PZE/VYt68KFb VdjWzRcMHHx2fTxx2KtD6LHABDbtBpo/0soD5MUEa9Y6CHMoMqCv/+1NeFfp2xewfJPx y52tmcOjYXO72q4GsiTFesO8Aco5VDwESCPgEIPxCrVkAeuGENd0GIUPYOVQHRYfVaGT GVfAEE8eivznQHuS2hb3/fKs7HfxmN7wz1hceU82XEWnx/h4cT++JeU53TmeGNQLQhI1 3UFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=+GX1IQDOxwUTPUe8Y5UJUWujZNd0dHuTLCJsq+WBnTg=; b=bxUWVbgQlboQKSTJBYoien7IBaDoEyHSs8Iu7GJmOqrAkLkuxSh03e5LaTG3ZF0DIu Jm/PaLQYSBhbacCYIeiSoVSmmblxXYwL79wlVgTcln+Qj39B6zToVZWg/4fzsIUww5mf XXK38lJ3z9Y//Lj/0HU1IE6SQf29FjT4DEi5fMgbEAl3Ifvh9w+U/jZi6SIZre8vONBD c/2pnFQF/wQOwlYQ6rW4jSv4JHvASEoQ/7A5VVhcs04l+yVSFZorQdvgld8OvuAOiWwZ rOWEy4NzDm0XYQsdAGhly8abwal0Ll6rdnX3CIoWNG9bxrwzKkq1h4tA7pIWCSRVNiwv EVVw== X-Gm-Message-State: AOAM530aBySaQKdkCTcr5THaArj3NUPQrTcilxE+w3Fb2wWExshaBItK mWKUSXqN4iFIE00SAHKU82A= X-Google-Smtp-Source: ABdhPJyIbzDeu8bYciwD/jBhw0N/jh0iO9oMZO0WJoYfeSiE2By2iett/JMiX4ZFA/2oactAhN493w== X-Received: by 2002:a63:d446:: with SMTP id i6mr669102pgj.479.1640232086895; Wed, 22 Dec 2021 20:01:26 -0800 (PST) Original-Received: from localhost (2403-5804-c6--add.ip6.aussiebb.net. [2403:5804:c6::add]) by smtp.gmail.com with ESMTPSA id s2sm3840041pfe.103.2021.12.22.20.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 20:01:26 -0800 (PST) Content-Disposition: inline In-Reply-To: <87ee64esqt.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:222967 Archived-At: Michael Albinus wrote: > "Trent W. Buck" writes: > > Is it reasonable for emacs to just chuck out arc-mode (and tar-mode > > and jka-compr) and instead just use libarchive? > > It's already used by vlc and a lot of GNOME stuff. > > > > libarchive already understands both .pyz and .crx3 files, at least for reading: … > > No. Neither .pyz nor .crx3? formats are supported by libarchive, I've just > tested it with Nautilus, the GNOME file manager. bsdtar uses several > archive libraries, I guess another archive library must be responsible > for these formats. Ah, sorry for the confusion. On my system (Debian 11) bsdtar is provided by "Source Package: libarchive" and only depends on libarchive13 and libc6, so I assumed it was a reasonable test of "what can libarchive do?". If it is using another library, I cannot see how: bash5$ ldd /usr/bin/bsdtar linux-vdso.so.1 (0x00007ffc6b1b3000) libarchive.so.13 => /lib/x86_64-linux-gnu/libarchive.so.13 (0x00007fdf3c997000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdf3c7d2000) libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007fdf3c78a000) libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007fdf3c77f000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fdf3c757000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fdf3c67c000) liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fdf3c657000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fdf3c644000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdf3c627000) libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x00007fdf3c479000) /lib64/ld-linux-x86-64.so.2 (0x00007fdf3ca8f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdf3c457000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdf3c44f000) libicuuc.so.67 => /lib/x86_64-linux-gnu/libicuuc.so.67 (0x00007fdf3c266000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdf3c122000) libicudata.so.67 => /lib/x86_64-linux-gnu/libicudata.so.67 (0x00007fdf3a609000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdf3a43c000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdf3a422000) bash5$ strace -f /usr/bin/bsdtar tf *.pyz |& grep -F -e exec -e fork execve("/usr/bin/bsdtar", ["/usr/bin/bsdtar", "tf", "MyCoolApp.pyz"], 0x7ffc169ca188 /* 70 vars */) = 0 Nor can I see embedded copies of libraries in https://salsa.debian.org/debian/libarchive/-/tree/master/tar My C-fu is not up to scratch, but Python has a thin FFI interface to libarchive, and that also works fine: bash5$ python3 Python 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import libarchive >>> with libarchive.file_reader('MyCoolApp.pyz') as z: ... for i in z: ... print(i.strmode, i.size, i.name, sep='\t') ... b'-rw-r--r--' 23 __main__.py b'-rw-r--r--' 0 __init__.py I had a quick look, but I can't immediately tell why nautilus would not work, as I cannot even find where nautilus uses libarchive. When I tested nautilus 3.38.2-1+deb11u1, it would not even open a .zip. It only offered to run file-roller. I found file-roller includes nautilus/nautilus-fileroller.c which uses a hard-coded archive_mime_types[] that it will activate for. application/x-chrome-extension (.crx3) is not in that list. There is no MIME type for .pyz because it's just a .zip with an optional shebang prepended ("#![^\n]*\n"). Nautilus and file-roller treat a .pyz WITHOUT a shebang identically to a .zip. Presumably this is due to libmagic-like MIME guessing. It seems to me that: 1. when given a file in pyz/crx/crx format, libarchive will auto-detect and use zip format. I think it just finds the zip archive at an offset, and leaves content before that offset alone. This would allow it to read/extract/edit existing pyz/crx/crx3, but not create a new one. This is also true for libarchive bsdtar and Info-ZIP unzip, although the latter emits a warning about the offset. 2. when given a file in pyz/crx/crx format, emacs arc-mode will not auto-detect zip format. 3. when given a file in pyz/crx/crx3 format, file-roller & nautilus will not auto-detect any format.