Bug#1053668: diffoscope: Consider using `file -i` as fallback for unknown file output
* Chris Lamb [2023-10-11 14:51]: > Niels Thykier wrote: > > > Digging a bit deeper, it turns out that `file -i` correctly classifies > > the changelog as `text/plain; charset=utf-8`. That is, `file` knows it > > is text and I suspect `diffoscope` should try `file -i` as well when it > > gets an unknown result from `file`. > > By "unknown result" I assume you mean that diffoscope cannot match > the file type with any known comparator. :) Indeed, diffoscope > doesn't recognise the bogus "Message Sequence Chart" so it falls > back to using a hexdump as you intuited. I would argue that this is a bug in file(1) as Magdir/communications uses a "string" test, which is for binary files. If this is a text file, not a binary format, it should be forcing a text file test by using "string/t" instead. That said, this is likely not the only such bug (I already encountered one before [1]), so the suggestion below makes sense to me. > I've got some WIP code that will treat unknown file types as text if > they have a MIME type of text/plain. This avoids the use of hexdump > with the examples you sent over at least. > > Do you think I should be further limiting that conditional to a > whitelist of safe encodings, too? (eg. "utf-8" and "us-ascii", etc.) I don't think we need to handle encodings differently from how we already handle files identified as text by file(1): the TextFile comparator tries to guess the encoding, but falls back to a hexdump for e.g. euc-jp encoded files which are identified as "unknown-8bit" by File.guess_encoding(), resulting in a LookupError from codecs.open(). - Fay [1] https://mailman.astron.com/pipermail/file/2023-February/001132.html
Bug#1052675: man-db: renders dashes as U+2010 breaking copy/paste of --long-options from man pages
Package: man-db Version: 2.12.0-1 Severity: normal X-Debbugs-Cc: f...@obfusk.net Hi! I ran into this before with curl in #1043309, but it seems many other man pages (e.g. apksigner, apksigcopier, pandoc, yt-dlp, etc.) are affected as well, which makes me wonder if this is not something that should be fixed in man instead. Example: $ man apksigner Now copy the string that looks like "--version" for the following two commands instead of typing it by hand: $ apksigner ‐‐version Unsupported command: ‐‐version. See --help for supported commands $ xxd <<< ‐‐version : e280 90e2 8090 7665 7273 696f 6e0a ..version. Typing it by hand with actual dashes (ASCII 0x2d) instead of U+2010: $ apksigner --version 0.9 $ xxd <<< --version : 2d2d 7665 7273 696f 6e0a --version. Workaround: $ LC_ALL=C man apksigner - Fay
Bug#1050438: dexdump: undefined symbol: _ZN12BacktraceMap6CreateEib
Package: dexdump Version: 13.0.0+r63-2 Severity: important X-Debbugs-Cc: f...@obfusk.net Hi! $ dexdump foo.dex dexdump: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libart.so.0: undefined symbol: _ZN12BacktraceMap6CreateEib I'm running sid (with e.g. android-libbase 1:34.0.4-1). Downgrading the various android packages to testing (android-libbase 1:33.0.3-2) made dexdump work again. Downgrading to bookworm (android-libbase 1:29.0.6-28) also works. $ aptitude search ~ahold ihA aapt - Android Asset Packaging Tool ih adb - Android Debug Bridge ihA android-framework-res - Android platform framework resources ihA android-libaapt - Android Asset Packaging Tool - Shared library ihA android-libandroidfw - Android utility library ihA android-libart - Android Runtime ihA android-libbacktrace - Android backtrace library ihA android-libbase - Android base library ihA android-libboringssl - Google's internal fork of OpenSSL for the Android SDK ihA android-libcutils - Android utils library for C ihA android-liblog - Android NDK logger interfaces ihA android-libnativebridge - Android native bridge library ihA android-libnativeloader - Android native loader library ihA android-libsparse - Library for sparse files ihA android-libutils - Android Utility Function Library ihA android-libziparchive - Library for ZIP archives ih android-libziparchive-dev - Library for ZIP archives - Development files ihA android-sdk-platform-tools-common - Tools for interacting with an Android platform - Common files ih dexdump - Displays information about Android DEX files ih fastboot - Android fastboot tool - FC
Bug#1050437: zipalign: undefined symbol: _ZN11zip_archive7InflateERKNS_6ReaderEjjPNS_6WriterEPm
Source: android-platform-build Version: 1:10.0.0+r36-1 Severity: important X-Debbugs-Cc: f...@obfusk.net Hi! $ zipalign foo.apk zipalign: symbol lookup error: zipalign: undefined symbol: _ZN11zip_archive7InflateERKNS_6ReaderEjjPNS_6WriterEPm I'm running sid (with e.g. android-libziparchive 1:34.0.4-1). Downgrading the various android packages to testing (android-libziparchive 1:33.0.3-2) didn't work (though it did fix a similar issue in dexdump). Downgrading them to bookworm (android-libziparchive 1:29.0.6-28) made zipalign work again. $ aptitude search ~ahold ihA aapt - Android Asset Packaging Tool ih adb - Android Debug Bridge ihA android-framework-res - Android platform framework resources ihA android-libaapt - Android Asset Packaging Tool - Shared library ihA android-libandroidfw - Android utility library ihA android-libart - Android Runtime ihA android-libbacktrace - Android backtrace library ihA android-libbase - Android base library ihA android-libboringssl - Google's internal fork of OpenSSL for the Android SDK ihA android-libcutils - Android utils library for C ihA android-liblog - Android NDK logger interfaces ihA android-libnativebridge - Android native bridge library ihA android-libnativeloader - Android native loader library ihA android-libsparse - Library for sparse files ihA android-libutils - Android Utility Function Library ihA android-libziparchive - Library for ZIP archives ih android-libziparchive-dev - Library for ZIP archives - Development files ihA android-sdk-platform-tools-common - Tools for interacting with an Android platform - Common files ih dexdump - Displays information about Android DEX files ih fastboot - Android fastboot tool - FC
Bug#1043309: curl: ‐‐connect‐timeout is weirdly broken
* Daniel Stenberg [2023-08-08 23:39]: > On Tue, 8 Aug 2023, FC Stegerman wrote: > > > $ curl ‐‐connect‐timeout > > curl: (6) Could not resolve host: xn--connecttimeout-462hah > > > > $ curl ‐‐connect‐timeout 2 -I example.com > > curl: (6) Could not resolve host: xn--connecttimeout-462hah > > Those dashes in there are not ascii minuses, they are unicode e2 80 90 (when > copied from the web page for this report), also known as Unicode Character > 'HYPHEN' (U+2010). > > Since they are not ascii minus (ascii byte code 45), they do not specify the > command line option --connect-timeout but that sequence of characters is > instead treaded as a "URL", which is converted from its unicode into > punycode before resolved. > > And on and on. This is not the bug it is made out to be. You are absolutely correct. And it makes sense now. That does leave a bug of sorts in the curl man page, which is where I copied that from. Looking at curl.1 I see: .IP "\-\-connect-timeout " [...] Examples: .nf curl --connect-timeout 20 https://example.com curl --connect-timeout 3.14 https://example.com .fi It seems that the unescaped dashes become U+2010. I was not expecting that, hence my not realising what was going on. Sorry about that. - FC
Bug#1043309: curl: ‐‐connect‐timeout is weirdly broken
Package: curl Version: 8.2.1-1 Severity: normal X-Debbugs-Cc: f...@obfusk.net Hi! Something seems to be going wrong here: $ curl ‐‐connect‐timeout curl: (6) Could not resolve host: xn--connecttimeout-462hah $ curl ‐‐connect‐timeout 2 -I example.com curl: (6) Could not resolve host: xn--connecttimeout-462hah [hangs] - FC
Bug#1031634: ITP: gum -- A tool for glamourous shell scripts
* Sam Hartman [2023-02-22 23:33]: [...] > >> A tool for glamorous shell scripts. Leverage the power of > >> Bubbles (https://github.com/charmbracelet/bubbles) and Lip > >> Gloss (https://github.com/charmbracelet/lipgloss) in your > >> scripts and aliases without writing any Go code! [...] > >> Gum provides highly configurable, ready-to-use utilities to > >> help you write useful shell scripts and dotfiles aliases > >> with just a few lines of code. > > Antonio> This last paragraph above looks like a good enough package > Antonio> description. Save everything else for an upstream README > Antonio> installed on /usr/share/doc/gum/, or some other type of > Antonio> documentation. > > I disagree. With what? Antonio said "last paragraph". The links to Bubbles and Lip Gloss are not in the last paragraph. The last paragraph does look alright to me, if a bit vague on what kind of utilities, so a brief description of Bubbles and Lip Gloss does seem useful to add. > I should not have to chase down links to websites to understand a > description No disagreement there. > Please include a phrase or two describing each of bubbles and gloss. No disagreement there -- if they are mentioned in the description. - FC
Bug#1031433: diffoscope: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Should be fixed by [1] - FC [1] https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/126
Bug#1030768: ITP: repro-apk -- scripts to make android apks reproducible
Package: wnpp Severity: wishlist Owner: FC Stegerman X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: repro-apk Version : 0.2.2 Upstream Contact: FC Stegerman * URL : https://github.com/obfusk/reproducible-apk-tools * License : GPLv3+ Programming Lang: Python Description : scripts to make android apks reproducible reproducible-apk-tools is a collection of scripts (available as subcommands of the repro-apk command) to help make APKs reproducible (e.g. by changing line endings from LF to CRLF), or find out why they are not (e.g. by comparing ZIP file metadata, or dumping baseline.prof files). repro-apk is used by e.g. F-Droid and also a proposed new optional dependency for diffoscope [1], allowing it to compare e.g. baseline.prof/baseline.profm files found in APKs. I am the upstream author and want to package and maintain it for Debian as well (like I already do with apksigcopier). - FC [1] https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/118
Bug#1030714: cwltool: please make the build reproducible
* Chris Lamb [2023-02-06 18:40]: > A patch is attached that removes all files (NB. not directories) that > are installed directly under that location (which can never be right). > This, therefore, is a more generic solution to #1030713. > - find .pybuild -name "out" -type f -delete > + find .pybuild -name "out" -type f > + find .pybuild/*/build -maxdepth 1 -type f -delete The patch keeps the original find command, just w/o the -delete, so it will now print a list of files named "out" instead of deleting them (or doing anything else with them) before deleting all files in the build subdirectories; was this intended? - FC
Bug#1026514: python-param: FTBFS: TypeError: The only supported seed types are: None,
* Dmitry Shachnev [2023-02-03 22:34]: > I think one more line is needed in debian/rules: > > export DEB_VERSION_UPSTREAM Indeed; thanks for pointing that out! - FC
Bug#1026514: python-param: FTBFS: TypeError: The only supported seed types are: None,
* Louis-Philippe Véronneau [2023-02-03 18:15]:
> On 2023-02-03 11 h 58, FC Stegerman wrote:
> > Presumably there is a way to get the version from e.g.
> > "dpkg-parsechangelog -S Version" (minus the -1 revision) instead. I'm
> > not sure how other packages handle this.
>
> You can get those values via the variables provided by
> /usr/share/dpkg/pkg-info.mk
>
> You can "source" those in your d/rules makefile by using:
>
> include /usr/share/dpkg/pkg-info.mk
Thanks!
Updating my previous suggestion based on this new information, it
becomes:
adding this to debian/rules
include /usr/share/dpkg/pkg-info.mk
and patching setup.py to change
def get_setup_version(reponame):
"""Use autover to get up to date version."""
# importing self into setup.py is unorthodox, but param has no
# required dependencies outside of python
from param.version import Version
return
Version.setup_version(os.path.dirname(__file__),reponame,archive_commit="$Format:%h$")
to e.g.
def get_setup_version(reponame):
"""Use autover to get up to date version."""
if version := os.environ.get("DEB_VERSION_UPSTREAM"):
return version
# importing self into setup.py is unorthodox, but param has no
# required dependencies outside of python
from param.version import Version
return
Version.setup_version(os.path.dirname(__file__),reponame,archive_commit="$Format:%h$")
- FC
Bug#1026514: python-param: FTBFS: TypeError: The only supported seed types are: None,
* FC Stegerman [2023-02-03 17:58]:
> * Andreas Tille [2023-02-03 17:01]:
> > I've bumped upstream version to 1.12.3 which basically has the
> > suggested patches applied but the issue remains as you can see
> > in Salsa CI
> >
> >https://salsa.debian.org/science-team/python-param/-/jobs/3891083
> >
> > Do you have any further hints?
>
> That looks like a different issue: get_setup_version() in setup.py
> seems to be trying to get the version from git, which of course fails
> when building the Debian package without the .git directory present.
>
> Presumably there is a way to get the version from e.g.
> "dpkg-parsechangelog -S Version" (minus the -1 revision) instead. I'm
> not sure how other packages handle this.
Again, I'm not sure what is considered best practice here, but
something like this should work:
adding this to debian/rules
export PARAM_PACKAGE_VERSION := $(shell dpkg-parsechangelog -S Version)
and patching setup.py to change
def get_setup_version(reponame):
"""Use autover to get up to date version."""
# importing self into setup.py is unorthodox, but param has no
# required dependencies outside of python
from param.version import Version
return
Version.setup_version(os.path.dirname(__file__),reponame,archive_commit="$Format:%h$")
to e.g.
def get_setup_version(reponame):
"""Use autover to get up to date version."""
if version := os.environ.get("PARAM_PACKAGE_VERSION"):
return version.split("-", 1)[0]
# importing self into setup.py is unorthodox, but param has no
# required dependencies outside of python
from param.version import Version
return
Version.setup_version(os.path.dirname(__file__),reponame,archive_commit="$Format:%h$")
- FC
Bug#1026514: python-param: FTBFS: TypeError: The only supported seed types are: None,
* Andreas Tille [2023-02-03 17:01]: > I've bumped upstream version to 1.12.3 which basically has the > suggested patches applied but the issue remains as you can see > in Salsa CI > >https://salsa.debian.org/science-team/python-param/-/jobs/3891083 > > Do you have any further hints? That looks like a different issue: get_setup_version() in setup.py seems to be trying to get the version from git, which of course fails when building the Debian package without the .git directory present. Presumably there is a way to get the version from e.g. "dpkg-parsechangelog -S Version" (minus the -1 revision) instead. I'm not sure how other packages handle this. - FC
Bug#1030335: python3-pip: PEP 668 support breaks --user/--editable
Package: python3-pip Version: 23.0+dfsg-1 Severity: important X-Debbugs-Cc: f...@obfusk.net Hi! I just updated python3-pip and was greeted with a NEWS message about PEP 668 support: This version of pip introduces PEP 668 support. Debian's python3.11 interpreter will soon (>= 3.11.1-3) declare the installation to be EXTERNALLY-MANAGED, instructing pip to disallow package installation outside virtualenvs. See: https://peps.python.org/pep-0668/ Practically, this means that you can't use pip to install packages outside a virtualenv, on a Debian system, any more. See /usr/share/doc/python3.11/README.venv for more details. If that isn't available yet, check: https://salsa.debian.org/cpython-team/python3/-/blob/master/debian/README.venv Not being able to install packages system-wide seems like a good idea, I fully support that. But I often install the Python packages I'm developing under my own user account with "pip install -e", which is also made impossible by this change. And I intentionally do not use virtualenvs for this because I want to have all dependencies provided by Debian packages, not downloaded from PyPI. And as far as I can tell there is not even an option I can give to pip to tell it to allow me to install to ~/.local anyway. PEP 668 mentions a --break-system-packages (as an example), but such an option doesn't seem to actually exist. - FC
Bug#1029066: diffoscope: FTBFS if no internet is available (using internet connection during build)
* Chris Lamb [2023-01-20 01:47]:
[...]
> As to a solution, though, I think this is somewhat blocking on Mattia's
> expertise in the generation of the Python test recommends. Are we, in
> essence, trying to parse the following data in setup.py?
>
> install_requires=[
> "python-magic",
> "libarchive-c",
> ],
> extras_require={
> "distro_detection": ["distro"],
> "cmdline": ["argcomplete", "progressbar"],
> "comparators": [
> "androguard",
> "binwalk",
> "defusedxml",
> "guestfs",
> "jsondiff",
> "python-debian",
> "pypdf",
> "pyxattr",
> "rpm-python",
> "tlsh",
> ],
> },
>
> If so, we don't necessarily have to wholesale move to pyproject.toml;
> instead, we could rejig setup.py...?
It seems that way. And doing so via pep517, which uses pip to install
the requirements in a temporary environment, which I assume is why it
accesses the network sometimes (but not always): to install missing
requirements when the Debian package is not already installed on the
system.
I've proposed an MR [1] that moves the extras_require to a JSON file
and uses that from both setup.py and generate-recommends.py; I've
confirmed it produces the same debian/tests/control.tmp as before.
- FC
[1] https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/121
Bug#1027946: AttributeError: 'AssertionError' object has no attribute 'message'
Package: python3-nose-random
Version: 1.0.0-4
Severity: normal
X-Debbugs-Cc: f...@obfusk.net
Running examples/tests.py from the package itself gives an expected
AssertionError, but an unexpected AttributeError:
==
ERROR: failing_test (test.RandomTestCase.failing_test)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/nose_random/__init__.py", line 65, in
randomized_test
test(self, scenario)
File "/tmp/fay/test.py", line 12, in failing_test
self.assertLess(x, y)
AssertionError: 0.7059478944679197 not less than 0.687797682192538
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/nose_random/__init__.py", line 69, in
randomized_test
raise type(e).with_traceback(type(e)('%s with scenario %s (%i of %i)' %
(e.message, rseed, i+1, nseeds)), sys.exc_info()[2])
^
AttributeError: 'AssertionError' object has no attribute 'message'
--
- FC
Bug#1026513: fixed patch
Hi!
Somehow, I accidentally created a reverse patch before; here's the
correct one.
- FC
--- a/nose_random/__init__.py 2023-01-04 23:12:59.008028925 +0100
+++ b/nose_random/__init__.py 2023-01-04 23:13:30.304246704 +0100
@@ -51,7 +51,7 @@
def randomize(n, scenario_generator, seed=12038728732):
def decorator(test):
def randomized_test(self):
-if config.scenario is not None:
+if config.scenario is not None and config.scenario is not _missing:
nseeds = 1
seeds = [config.scenario]
else:
@@ -70,4 +70,4 @@
else:
raise (type(e), type(e)('%s with scenario %s (%i of %i)' % (e.message, rseed, i+1, nseeds)), sys.exc_info()[2])
return randomized_test
-return decorator
\ No newline at end of file
+return decorator
Bug#1026513: patch seems incorrect, here's a better one
Hi!
The package description for python3-nose-random says:
* uses a fixed seed so that each test run is identical
* lets you to run the test only on a specific scenario to facilitate
debugging
I'm not very familiar with this package, but the removal of rseed in
the patch seems to me to break those properties, since it no longer
uses a fixed seed.
The real problem seems to be that config.scenario can be _missing,
which is an object() instead of a supported seed type.
I've attached a patch that fixes the original problem -- jsondiff's
tests no longer fail -- without removing the use of rseed.
- FC
--- a/nose_random/__init__.py 2023-01-04 07:38:06.340805543 +0100
+++ b/nose_random/__init__.py 2016-10-19 11:17:54.0 +0200
@@ -51,7 +51,7 @@
def randomize(n, scenario_generator, seed=12038728732):
def decorator(test):
def randomized_test(self):
-if config.scenario is not None and config.scenario is not _missing:
+if config.scenario is not None:
nseeds = 1
seeds = [config.scenario]
else:
@@ -70,4 +70,4 @@
else:
raise (type(e), type(e)('%s with scenario %s (%i of %i)' % (e.message, rseed, i+1, nseeds)), sys.exc_info()[2])
return randomized_test
-return decorator
+return decorator
\ No newline at end of file
Bug#1026976: Upcoming test suite regression due to changes in file/libmagic
* Christoph Biedl [2023-01-01 18:17]:
> > As I understand it, this is result of how t/fixtures/pyzip/pyzip.in is
> > described by file(1):
> >
> > - a /usr/bin/python3 script executable (binary data)
> > + Zip archive, with extra data prepended
>
> Thanks to FC Stegerman, this has been fixed upstream. So this bug now
> belongs into the domain of the file package, and will be fixed in the
> next upload.
Unfortunately, that's not completely correct. Whilst IMO my patch for
file makes its output "more correct", it's still different from the
output that strip-nondeterminism currently expects:
- a /usr/bin/python3 script executable (binary data)
+ a /usr/bin/python3 script executable (Zip archive)
I've attached a patch for matching both old and new output and opened
a merge request [1] on salsa as well.
- FC
[1]
https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/merge_requests/15
diff --git a/lib/File/StripNondeterminism.pm b/lib/File/StripNondeterminism.pm
index fc5451e..338a514 100644
--- a/lib/File/StripNondeterminism.pm
+++ b/lib/File/StripNondeterminism.pm
@@ -111,7 +111,7 @@ sub get_normalizer_for_file($) {
}
# pyzip - check last due to call to file(1)
- if (_get_file_type($_) =~ m/python3 script executable \(binary data\)/) {
+ if (_get_file_type($_) =~ m/python3 script executable \((Zip archive|binary data)\)/) {
my $handler = _handler('pyzip');
return $handler
if File::StripNondeterminism::handlers::pyzip::is_pyzip_file($_);
Bug#1026976: Upcoming test suite regression due to changes in file/libmagic
* Christoph Biedl [2022-12-29 16:39]: > Chris Lamb wrote... > > However, this "extra data prepended" doesn't fit well under the rubric > > of "data". Yes, this "#!/usr/bin/python3\n" shebang is definitely > > "data" of a kind, but a shebang isn't really data in that way given > > the special-treatment afforded to it by UNIX systems. Even if this > > noun was replaced by the more general "bytes", the magic nature of the > > shebang would still remain… as would the desire to discriminate > > between pyzip files and other ZIP files with prepended data. > > > > Could another — different — string be emitted in the case that these > > prepended bytes are a shebang? We could potentially look for the file > > starting with #! and for that to take precedence over this new case. > > After some more thinking: I suggest you do nothing for the time being > while I take this to upstream. If all else fails, I'll revert the change > for the next upload. By the way, that will be 1:5.44-1, but the changes > to 1:5.43-3 are minimal. FWIW I've attached a patch that makes it discriminate between ZIP files with prepended data with or without a shebang: $ file -b zipfile-with-data-prepended Zip archive, with extra data prepended $ file -b pyzip a /usr/bin/python3 script executable (Zip archive) I'm not sure that completely solves the issue, because there could be other (executable) file formats affected, not just pyzip and other formats using a shebang. So perhaps reverting the change completely is better after all. We probably need upstream to figure that out. - FC Index: file-5.43/magic/Magdir/archive === --- file-5.43.orig/magic/Magdir/archive 2022-12-31 00:33:43.0 +0100 +++ file-5.43/magic/Magdir/archive 2022-12-31 01:05:17.245343109 +0100 @@ -1876,9 +1876,14 @@ # https://en.wikipedia.org/wiki/ZIP_(file_format)#End_of_central_directory_record_(EOCD) # by Michal Gorny -2 uleshort 0 ->&-22 string PK\005\006 Zip archive, with extra data prepended +>&-22 string PK\005\006 +# without #! +>>0 string !#! Zip archive, with extra data prepended !:mime application/zip !:ext zip/cbz +# with #! +>>0 string/w #!\ a +>>>&-1 string/T x %s script executable (Zip archive) # ACE archive (from http://www.wotsit.org/download.asp?f=ace) # by Stefan `Sec` Zehl
Bug#1026976: Upcoming test suite regression due to changes in file/libmagic
* Christoph Biedl [2022-12-25 14:20]: > As I understand it, this is result of how t/fixtures/pyzip/pyzip.in is > described by file(1): > > - a /usr/bin/python3 script executable (binary data) > + Zip archive, with extra data prepended > > Now that looks a bit delicate ... if you think this is something that > should be handled in file/libmagic, let me know. [Disclaimer: this is just my personal opinion, I'm an RB contributor but not involved in maintaining strip-nondeterminism.] IMO that seems like a useful change in and of itself, but perhaps not something that should take precedence over a #! line. Perhaps something like a /usr/bin/python3 script executable (Zip archive) would be ideal in this case, but I imagine that might not be trivial to implement. Thanks! - FC
Bug#1023044: ITP: apksigtool -- parse/verify/clean android apk signing blocks & apks
Package: wnpp Severity: wishlist Owner: FC Stegerman X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: apksigtool Version : 0.5.0 Upstream Author : FC Stegerman * URL : https://github.com/obfusk/apksigtool * License : AGPLv3+ Programming Lang: Python Description : parse/verify/clean android apk signing blocks & apks apksigtool is a tool for parsing android APK Signing Blocks (either embedded in an APK or extracted as a separate file, e.g. using apksigcopier) and verifying APK signatures. It can also clean them (i.e. remove everything that's not an APK Signature Scheme v2/v3 Block or verity padding block), which can be useful for reproducible builds. WARNING: verification is considered EXPERIMENTAL and SHOULD NOT BE RELIED ON, please use apksigner instead. apksigtool is a proposed new optional dependency for diffoscope [1], allowing it to properly compare APK Signing Blocks. I am the upstream author and want to package and maintain it for Debian as well (like I already do with apksigcopier). I am looking for a sponsor, since I am (still) a Sponsored Maintainer. NB: v0.5.0 hasn't actually been released yet, but it will be soon. - FC [1] https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/320
