all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Trent W. Buck" <trentbuck@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: stefan@marxist.se, 52477@debbugs.gnu.org
Subject: bug#52477: 27.1; .crx and .crx3 are zip files
Date: Thu, 23 Dec 2021 15:01:20 +1100	[thread overview]
Message-ID: <YcP0kNVEH8KqWoxs@hera.lan> (raw)
In-Reply-To: <87ee64esqt.fsf@gmx.de>

Michael Albinus wrote:
> "Trent W. Buck" <trentbuck@gmail.com> 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.






  reply	other threads:[~2021-12-23  4:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14  4:56 bug#52477: 27.1; .crx and .crx3 are zip files Trent W. Buck
2021-12-15 20:51 ` Stefan Kangas
2021-12-16  8:56   ` Michael Albinus
2021-12-16  9:22     ` Eli Zaretskii
2021-12-16 11:59       ` Michael Albinus
2021-12-16 13:21         ` Eli Zaretskii
2021-12-19 13:09           ` Lars Ingebrigtsen
2021-12-22  3:50           ` Trent W. Buck
2021-12-22 12:20             ` Michael Albinus
2021-12-23  4:01               ` Trent W. Buck [this message]
2021-12-24 13:51                 ` Michael Albinus
2021-12-22 12:55             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YcP0kNVEH8KqWoxs@hera.lan \
    --to=trentbuck@gmail.com \
    --cc=52477@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.