Comments (9)
The hashing bugs have been fixed on main
. Please test the next continuous build and report back. I'll create a new tag once I hear from you.
from appimageupdate.
@TheAssassin works now. thx.
from appimageupdate.
You may understand that I'll need some example data to reproduce your bug...
from appimageupdate.
Ok, the following example for testing:
The GPG key from here
wget https://build.opensuse.org/projects/home:munix9/public_key
Imported using: gpg2 --import public_key
(gpg2 --edit-key BDF3F6ACD4D81407
- set to trust ultimately)
An outdated AppImage from this mirror
wget https://ftp.gwdg.de/pub/opensuse/repositories/home:/munix9/AppImage/celestia-1.6.2.2-lp152.13.1.Build13.7.glibc2.17-x86_64.AppImage
The appimageupdatetool AppImage
wget https://github.com/AppImage/AppImageUpdate/releases/download/2.0.0-alpha-1-20220123/appimageupdatetool-x86_64.AppImage
chmod 755 appimageupdatetool-x86_64.AppImage
sudo ln -s /var/lib/ca-certificates/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt
./appimageupdatetool-x86_64.AppImage celestia-1.6.2.2-lp152.13.1.Build13.7.glibc2.17-x86_64.AppImage
Checking for updates...
zsync2: Found SHA256 digest: 9e064f413376895da5d7e10f6823bd47ac0da1119ef16c1a50d667e81f320e57
zsync2: Verified instance digest of redirected .zsync response
... done!
Starting update...
Updating from generic server via ZSync
0% done
zsync2: Found SHA256 digest: 9e064f413376895da5d7e10f6823bd47ac0da1119ef16c1a50d667e81f320e57
zsync2: Verified instance digest of redirected .zsync response
zsync2: Target file: /home/test/AppImage/celestia-1.6.2.2-lp153.27.1.Build27.9.glibc2.29-x86_64.AppImage
zsync2: Reading seed file: celestia-1.6.2.2-lp152.13.1.Build13.7.glibc2.17-x86_64.AppImage
80.24% done (39.21 of 48.86 MiB)...
zsync2: Usable data from seed files: 81.988248%
zsync2: Renaming temp file
zsync2: Fetching remaining blocks
81.99% done (40.06 of 48.86 MiB)...
zsync2: Downloading from https://rsync.opensuse.org/repositories/home:/munix9/AppImage/celestia-1.6.2.2-lp153.27.1.Build27.9.glibc2.29-x86_64.AppImage
zsync2: optimized ranges, old requests count 27, new requests count 5
99.60% done (48.66 of 48.86 MiB)...
zsync2: Verifying downloaded file
100.00% done (48.86 of 48.86 MiB)...
zsync2: checksum matches OK
zsync2: used 42006528 local, fetched 10110920
100.00% done (48.86 of 48.86 MiB)...
/usr/bin/gpg2: gpg: Signature made Fri Oct 1 10:31:18 2021 CEST
/usr/bin/gpg2: gpg: using RSA key BDF3F6ACD4D81407
/usr/bin/gpg2: gpg: BAD signature from "home:munix9 OBS Project <home:[email protected]>" [ultimate]
/usr/bin/gpg2: gpg: Signature made Thu Jan 20 18:28:36 2022 CET
/usr/bin/gpg2: gpg: using RSA key BDF3F6ACD4D81407
/usr/bin/gpg2: gpg: BAD signature from "home:munix9 OBS Project <home:[email protected]>" [ultimate]
Validation error: Bad signature
Restoring original file
Output of an "old" appimageupdatetool:
Checking for updates...
zsync2: Found SHA256 digest: 9e064f413376895da5d7e10f6823bd47ac0da1119ef16c1a50d667e81f320e57
zsync2: Verified instance digest of redirected .zsync response
... done!
Starting update...
Updating from generic server via ZSync
0% done
zsync2: Found SHA256 digest: 9e064f413376895da5d7e10f6823bd47ac0da1119ef16c1a50d667e81f320e57
zsync2: Verified instance digest of redirected .zsync response
zsync2: Target file: /home/test/AppImage/celestia-1.6.2.2-lp153.27.1.Build27.9.glibc2.29-x86_64.AppImage
zsync2: Reading seed file: celestia-1.6.2.2-lp152.13.1.Build13.7.glibc2.17-x86_64.AppImage
47.05% done (22.99 of 48.86 MiB)...
zsync2: Usable data from seed files: 81.988248%
zsync2: Renaming temp file
zsync2: Fetching remaining blocks
81.99% done (40.06 of 48.86 MiB)...
zsync2: Downloading from https://rsync.opensuse.org/repositories/home:/munix9/AppImage/celestia-1.6.2.2-lp153.27.1.Build27.9.glibc2.29-x86_64.AppImage
zsync2: optimized ranges, old requests count 27, new requests count 5
99.37% done (48.55 of 48.86 MiB)...
zsync2: Verifying downloaded file
100.00% done (48.86 of 48.86 MiB)...
zsync2: checksum matches OK
zsync2: used 42006528 local, fetched 10110920
100.00% done (48.86 of 48.86 MiB)...
/usr/bin/gpg2: gpg: Signature made Fri Oct 1 10:31:18 2021 CEST
/usr/bin/gpg2: gpg: using RSA key BDF3F6ACD4D81407
/usr/bin/gpg2: gpg: Good signature from "home:munix9 OBS Project <home:[email protected]>" [ultimate]
/usr/bin/gpg2: gpg: Signature made Thu Jan 20 18:28:36 2022 CET
/usr/bin/gpg2: gpg: using RSA key BDF3F6ACD4D81407
/usr/bin/gpg2: gpg: Good signature from "home:munix9 OBS Project <home:[email protected]>" [ultimate]
Signature validation passed
Update successful. New file created: /home/test/AppImage/celestia-1.6.2.2-lp153.27.1.Build27.9.glibc2.29-x86_64.AppImage
from appimageupdate.
I've tried to update the AppImage you linked to. My local build does not extract a key from .sig_key
even. Something weird is going on. That code has not been modified recently.
Edit: celestia-1.6.2.2-lp152.13.1.Build13.7.glibc2.17-x86_64.AppImage
does not embed a key for signing. .sha256_sig
is populated, though. AppImageUpdate cannot validate a signature without an embedded key.
from appimageupdate.
I don't understand now, that worked in the past.
Do you mean that one? And what exactly is missing?
objdump -s -j .sha256_sig celestia-1.6.2.2-lp152.13.1.Build13.7.glibc2.17-x86_64.AppImage
celestia-1.6.2.2-lp152.13.1.Build13.7.glibc2.17-x86_64.AppImage: file format elf64-x86-64
Contents of section .sha256_sig:
0000 2d2d2d2d 2d424547 494e2050 47502053 -----BEGIN PGP S
0010 49474e41 54555245 2d2d2d2d 2d0a5665 IGNATURE-----.Ve
0020 7273696f 6e3a2047 6e755047 2076312e rsion: GnuPG v1.
0030 302e3720 28474e55 2f4c696e 7578290a 0.7 (GNU/Linux).
0040 0a695145 56417755 41595662 48567233 .iQEVAwUAYVbHVr3
0050 7a39717a 55324251 4841516a 584f6766 z9qzU2BQHAQjXOgf
0060 39475770 41334869 64357653 614e5467 9GWpA3Hid5vSaNTg
0070 53474642 62417336 44542b50 63446c51 SGFBbAs6DT+PcDlQ
0080 2f0a5248 65777138 555a6777 39515677 /.RHewq8UZgw9QVw
0090 42335249 66416142 5834664c 51417376 B3RIfAaBX4fLQAsv
00a0 48687567 62786d68 46452f51 436f3232 HhugbxmhFE/QCo22
00b0 56336146 67516862 2f707758 5a4d6759 V3aFgQhb/pwXZMgY
00c0 75390a51 39484543 44524551 306d5243 u9.Q9HECDREQ0mRC
00d0 466f3944 76377054 57727052 52596e4f Fo9Dv7pTWrpRRYnO
00e0 506c662b 675a6649 4f5a5461 76784c75 Plf+gZfIOZTavxLu
00f0 6b546b69 564f756b 75447a4d 4c716151 kTkiVOukuDzMLqaQ
0100 782f380a 587a7379 42566251 4b6d7344 x/8.XzsyBVbQKmsD
0110 556f3064 39574b35 5577565a 514e482b Uo0d9WK5UwVZQNH+
0120 69467a4c 35797a78 527a4f50 76725977 iFzL5yzxRzOPvrYw
0130 74576c7a 6d385a4b 71727a56 734b427a tWlzm8ZKqrzVsKBz
0140 307a6544 0a505154 54647036 6b746d59 0zeD.PQTTdp6ktmY
0150 364f4931 38486c64 33445577 70617a2f 6OI18Hld3DUwpaz/
0160 66702b71 33615543 2f487569 37757a39 fp+q3aUC/Hui7uz9
0170 5a6f5970 656a4a70 65415a42 68664855 ZoYpejJpeAZBhfHU
0180 48303831 450a3647 4a45614a 71643434 H081E.6GJEaJqd44
0190 545a742b 4c494e4a 4a6a6179 71365059 TZt+LINJJjayq6PY
01a0 78683959 5832592b 78705839 2b4b2b4b xh9YX2Y+xpX9+K+K
01b0 4637782f 4a4d457a 73654f51 3d3d0a3d F7x/JMEzseOQ==.=
01c0 55726e43 0a2d2d2d 2d2d454e 44205047 UrnC.-----END PG
01d0 50205349 474e4154 5552452d 2d2d2d2d P SIGNATURE-----
01e0 0a000000 00000000 00000000 00000000 ................
01f0 00000000 00000000 00000000 00000000 ................
0200 00000000 00000000 00000000 00000000 ................
0210 00000000 00000000 00000000 00000000 ................
0220 00000000 00000000 00000000 00000000 ................
0230 00000000 00000000 00000000 00000000 ................
0240 00000000 00000000 00000000 00000000 ................
0250 00000000 00000000 00000000 00000000 ................
0260 00000000 00000000 00000000 00000000 ................
0270 00000000 00000000 00000000 00000000 ................
0280 00000000 00000000 00000000 00000000 ................
0290 00000000 00000000 00000000 00000000 ................
02a0 00000000 00000000 00000000 00000000 ................
02b0 00000000 00000000 00000000 00000000 ................
02c0 00000000 00000000 00000000 00000000 ................
02d0 00000000 00000000 00000000 00000000 ................
02e0 00000000 00000000 00000000 00000000 ................
02f0 00000000 00000000 00000000 00000000 ................
0300 00000000 00000000 00000000 00000000 ................
0310 00000000 00000000 00000000 00000000 ................
0320 00000000 00000000 00000000 00000000 ................
0330 00000000 00000000 00000000 00000000 ................
0340 00000000 00000000 00000000 00000000 ................
0350 00000000 00000000 00000000 00000000 ................
0360 00000000 00000000 00000000 00000000 ................
0370 00000000 00000000 00000000 00000000 ................
0380 00000000 00000000 00000000 00000000 ................
0390 00000000 00000000 00000000 00000000 ................
03a0 00000000 00000000 00000000 00000000 ................
03b0 00000000 00000000 00000000 00000000 ................
03c0 00000000 00000000 00000000 00000000 ................
03d0 00000000 00000000 00000000 00000000 ................
03e0 00000000 00000000 00000000 00000000 ................
03f0 00000000 00000000 00000000 00000000 ................
from appimageupdate.
Well define "past". There must be a key in .sig_key
for the validation to work. AppImageUpdate expects a key to be embedded inside the AppImage. Importing a key manually makes no sense, it never has.
For years, the official AppImageKit appimagetool has embedded the key used for signing into the AppImage, allowing AppImageUpdate to validate signatures, and establish a chain of trust (if we trust the old AppImage and it has been signed properly, we can trust the new AppImage if it has been signed properly with the exactly same key). AppImageUpdate even creates a temporary GPG keyring into which it extracts the keys from both the old and new AppImage which is used for validating the signatures.
I don't know how OBS works there and what outdated tools it uses. I've just verified that AppImages built with the official appimagetool still have an ELF section called .sig_key
containing a key, and that the extraction works as expected.
Your use case, as you describe it, was the initial poor state of signature support within AppImageUpdate. As said, shipping signatures without shipping the keys has never made any sense at all, hence we started to embed the pubkeys. Your use case has not been supported since, and I am not sure why GPG would even check your home keyring at all, given we pass --keyring
explicitly. Perhaps it's because we use a tool from the system and don't ship a "known good" one.
Regarding the hash calculation, you seem to be right, something is broken there. I'll have a look. However, I won't be using your AppImage for testing, since your use case uses some undefined behavior. I'd strongly(!) recommend you to make sure your AppImages contain a .sig_key
. Since this really looks like an OBS bug (i.e., they're using some super outdated software), you might want to contact them as well.
from appimageupdate.
I've re-read the man page:
--keyring file
Add file to the current list of keyrings. If file begins with a tilde and a slash, these are
replaced by the $HOME directory. If the filename does not contain a slash, it is assumed to be
in the GnuPG home directory ("~/.gnupg" if --homedir or $GNUPGHOME is not used).
[...]
I didn't realize that the keyring was added to the list, i.e., the home keyring may be used as a fallback. Still, OBS should embed the keys. Please report this bug to them.
from appimageupdate.
Thanks for your effort and help, I will check the implementation in OBS regarding this.
from appimageupdate.
Related Issues (20)
- Dotnet core interoperability question
- Updater Constructor does not actually throw std::invalid_argument
- GithubReleasesUpdateInformation::buildUrl is writing to the console HOT 2
- Reduce amount of api calls. HOT 2
- Option to ignore appimages in specified directories? HOT 2
- Feature request: allow overriding AppImage updInfo HOT 6
- "Could NOT find CURL (missing: HTTP)" while building on Ubuntu 14 HOT 12
- Incompatibility when dynamically linking libappimageupdate in GTK app HOT 10
- Assembled ZSync URL points to wrong file
- command line flags missing HOT 6
- No rule to make target libarchive.a
- Why can't AppImageUpdate update itself when prompted by the user? HOT 7
- Patch apps for update HOT 2
- Remove "alpha" from the version
- Unclear downloads in the release page, and no information in the readme HOT 1
- Update panel shortcut HOT 1
- double click closes the file-chooser HOT 1
- [Feature request] Multiple selection
- Unable to build for armhf HOT 15
- Thank you!
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from appimageupdate.