Having downloaded the torrent and burned the iso to a dvd I verified the torrent using sha256sum but apparently that wasn't enough since the installation broke part of the way through which means I ought to have used the gpg verification that is available online. What is done with those asc files to verify a download? I used lftp with no options on the command line and maybe that was also a mistake on my part. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.
Hi, the download page as well as the installation guide describe what to do. I didn't copy the description, the details are provided by those links. "[...] With this key the signature can be verified like this: sq [...]" - https://archlinux.org/download/ "1.2 Verify signature [...] gpg" - https://wiki.archlinux.org/title/Installation_guide#Verify_signature Regards, Ralf
The wiki has gotten more difficult to find useable material over the years with lynx. Many controls on it don't work since javascript supports and runs that wiki and lynx will never do javascript. The first time I accessed that installation_guide several years ago, the wiki had no sidebar on it. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Tue, 29 Aug 2023, Ralf Mardorf wrote:
Hi,
the download page as well as the installation guide describe what to do. I didn't copy the description, the details are provided by those links.
"[...] With this key the signature can be verified like this:
sq [...]" - https://archlinux.org/download/
"1.2 Verify signature [...] gpg" - https://wiki.archlinux.org/title/Installation_guide#Verify_signature
Regards, Ralf
What package has sq in it? -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Tue, 29 Aug 2023, Ralf Mardorf wrote:
Hi,
the download page as well as the installation guide describe what to do. I didn't copy the description, the details are provided by those links.
"[...] With this key the signature can be verified like this:
sq [...]" - https://archlinux.org/download/
"1.2 Verify signature [...] gpg" - https://wiki.archlinux.org/title/Installation_guide#Verify_signature
Regards, Ralf
Having downloaded the torrent and burned the iso to a dvd I verified the torrent using sha256sum but apparently that wasn't enough since the installation broke part of the way through which means I ought to have used the gpg verification that is available online. What is done with those asc files to verify a download? I used lftp with no options on the command line and maybe that was also a mistake on my part. Hello,
If the ISO has a matching SHA-256,⁽¹⁾ then it’s not damaged. If you downloaded it over torrent, it’s also not damaged, as the client already verifies the content.⁽²⁾ Using a PGP signature is meant to prove authenticity of the ISO: that it came from rightful Arch maintainers and not a malicious actor. However, to make SHA-256 hash match, that actor would need to have control over either Arch website or your HTTPS connection to it. If they did, verifying the ISO with a key you obtained through the same route wouldn’t help help at all. Even more, an attacker would typically avoid breaking the ISO. So, while verifying the PGP signature is the best practice and I strongly encourage you to use it whenever possible, in this case you are likely facing a different problem. How did the installation “broke part of the way through”? ____ ⁽¹⁾ 3bf1287333de5c26663b70a17ce7573f15dc60780b140cbbd1c720338c0abac5 ⁽²⁾ Though v1 torrent hashes only protect against random errors, not intentional modifications.
gpg --keyserver-options auto-key-retrieve --verify archlinux-version-x86_64.iso.sig stated the signature didn't exist. I got that off the Installation_guide so trashed that archlinux disk. I used aria2c -V -l archlinux.log followed by the current torrent name. end result was a failure to install with all manner of python errors before I tried to get the signature and verify the disk. We have here verizon fios and that's turned into an unreliable internet connection since August of 2022. The owner of the account hasn't got time to straighten any of the problems out and so far as that account is concerned I'm just a user. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Thu, 31 Aug 2023, mpan wrote:
Having downloaded the torrent and burned the iso to a dvd I verified the torrent using sha256sum but apparently that wasn't enough since the installation broke part of the way through which means I ought to have used the gpg verification that is available online. What is done with those asc files to verify a download? I used lftp with no options on the command line and maybe that was also a mistake on my part. Hello,
If the ISO has a matching SHA-256,⁽¹⁾ then it’s not damaged. If you downloaded it over torrent, it’s also not damaged, as the client already verifies the content.⁽²⁾
Using a PGP signature is meant to prove authenticity of the ISO: that it came from rightful Arch maintainers and not a malicious actor. However, to make SHA-256 hash match, that actor would need to have control over either Arch website or your HTTPS connection to it. If they did, verifying the ISO with a key you obtained through the same route wouldn’t help help at all. Even more, an attacker would typically avoid breaking the ISO.
So, while verifying the PGP signature is the best practice and I strongly encourage you to use it whenever possible, in this case you are likely facing a different problem. How did the installation “broke part of the way through”?
____ ⁽¹⁾ 3bf1287333de5c26663b70a17ce7573f15dc60780b140cbbd1c720338c0abac5 ⁽²⁾ Though v1 torrent hashes only protect against random errors, not intentional modifications.
If the SHA-256 hash agrees, the file did not sustain any damage in transit. It does not matter how unreliable your connection is. If the file seen any unintentional, random changes, SHA-256 would not agree. The same holds for SHA-1, which is checked by torrent clients.⁽¹⁾ Your file is not damaged. Hypothetically you may be falling victim to a malicious agent, but the picture I see does not put this scenario among most likely explanations of your trouble. I absolutely support you wish to do proper security, but I believe this will not lead to overcoming the problem. To resolve the issue, we need to know, what exactly happens and where. What command do you execute, at which stage of the installation (please refer to the specific part of the Arch Wiki), what are the errors? “failure to install with all manner of python errors before I tried to get the signature and verify the disk” is not only letting us understand, what is happening. It is making things confusing, because signature verification is done before Arch ISO is even used. As for errors from `gpg --verify`: is this the actual, exact error message gpg printed? If not, in future please do not paraphrase errors: it really makes helping harder. I guess you might’ve received an error about gpg not being able to open the signature file. Does the file exist? ____ ⁽¹⁾ Based on documentation, aria2 seems to disable integrity checks by default. I was not aware of this before and imagine astonishment on my face. But this does not apply to your case, because of the `-V` option.
I used a flash drive earlier and removed it but now have an /dev/sdb drive with 8 megs size on the computer that remains after power is shut off when power is turned on again. Has anyone had anything like this happen before and what could cause this? I downloaded an iso with aria2c earlier and got the gpg key for that iso and tried verifying the iso with the included .asc files and got a bad gpg signature returned on verification. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Thu, 31 Aug 2023, mpan wrote:
If the SHA-256 hash agrees, the file did not sustain any damage in transit. It does not matter how unreliable your connection is. If the file seen any unintentional, random changes, SHA-256 would not agree. The same holds for SHA-1, which is checked by torrent clients.⁽¹⁾ Your file is not damaged.
Hypothetically you may be falling victim to a malicious agent, but the picture I see does not put this scenario among most likely explanations of your trouble. I absolutely support you wish to do proper security, but I believe this will not lead to overcoming the problem.
To resolve the issue, we need to know, what exactly happens and where. What command do you execute, at which stage of the installation (please refer to the specific part of the Arch Wiki), what are the errors? “failure to install with all manner of python errors before I tried to get the signature and verify the disk” is not only letting us understand, what is happening. It is making things confusing, because signature verification is done before Arch ISO is even used.
As for errors from `gpg --verify`: is this the actual, exact error message gpg printed? If not, in future please do not paraphrase errors: it really makes helping harder. I guess you might’ve received an error about gpg not being able to open the signature file. Does the file exist?
____ ⁽¹⁾ Based on documentation, aria2 seems to disable integrity checks by default. I was not aware of this before and imagine astonishment on my face. But this does not apply to your case, because of the `-V` option.
Hi, to demonstrate how to verify the ISO I didn't use the torrent. 1. • rocketmouse@archlinux /tmp/verification_demo $ wget --quiet http://ftp.agdsn.de/pub/mirrors/archlinux/iso/2023.08.01/archlinux-2023.08.01-x86_64.iso{,.sig} • rocketmouse@archlinux /tmp/verification_demo $ sq wkd get pierre@archlinux.org -o release-key.pgp • rocketmouse@archlinux /tmp/verification_demo $ sq verify --signer-file release-key.pgp --detached archlinux-2023.08.01-x86_64.iso.sig archlinux-2023.08.01-x86_64.iso Good signature from 76A5EF9054449A5C ("Pierre Schmitz <pierre@archlinux.org>") 1 good signature. • rocketmouse@archlinux /tmp/verification_demo $ echo $? 0 2. • rocketmouse@archlinux /tmp/verification_demo $ gpg --keyserver-options auto-key-retrieve --verify archlinux-2023.08.01-x86_64.iso.sig gpg: assuming signed data in 'archlinux-2023.08.01-x86_64.iso' gpg: Signature made Tue 01 Aug 2023 14:19:49 CEST gpg: using EDDSA key 3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C gpg: issuer "pierre@archlinux.org" gpg: key 76A5EF9054449A5C: public key "Pierre Schmitz <pierre@archlinux.org>" imported gpg: key 7F2D434B9741E8AC: public key "Pierre Schmitz <pierre@archlinux.org>" imported gpg: Total number processed: 2 gpg: imported: 2 gpg: Note: third-party key signatures using the SHA1 algorithm are rejected gpg: no ultimately trusted keys found gpg: Good signature from "Pierre Schmitz <pierre@archlinux.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 3E80 CA1A 8B89 F69C BA57 D98A 76A5 EF90 5444 9A5C • rocketmouse@archlinux /tmp/verification_demo $ echo $? 0 3. • rocketmouse@archlinux /tmp/verification_demo $ pacman-key -v archlinux-2023.08.01-x86_64.iso.sig ==> Checking archlinux-2023.08.01-x86_64.iso.sig... (detached) gpg: Signature made Tue 01 Aug 2023 14:19:49 CEST gpg: using EDDSA key 3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C gpg: issuer "pierre@archlinux.org" gpg: Note: trustdb not writable gpg: Good signature from "Pierre Schmitz <pierre@archlinux.org>" [full] gpg: aka "Pierre Schmitz <pierre@archlinux.de>" [unknown] • rocketmouse@archlinux /tmp/verification_demo $ echo $? 0 Regards, Ralf
-- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Fri, 1 Sep 2023, Ralf Mardorf wrote:
Hi,
to demonstrate how to verify the ISO I didn't use the torrent.
1.
• rocketmouse@archlinux /tmp/verification_demo $ wget --quiet http://ftp.agdsn.de/pub/mirrors/archlinux/iso/2023.08.01/archlinux-2023.08.01-x86_64.iso{,.sig} • rocketmouse@archlinux /tmp/verification_demo $ sq wkd get pierre@archlinux.org -o release-key.pgp • rocketmouse@archlinux /tmp/verification_demo $ sq verify --signer-file release-key.pgp --detached archlinux-2023.08.01-x86_64.iso.sig archlinux-2023.08.01-x86_64.iso Good signature from 76A5EF9054449A5C ("Pierre Schmitz <pierre@archlinux.org>")
1 good signature. • rocketmouse@archlinux /tmp/verification_demo $ echo $? 0
2.
• rocketmouse@archlinux /tmp/verification_demo $ gpg --keyserver-options auto-key-retrieve --verify archlinux-2023.08.01-x86_64.iso.sig gpg: assuming signed data in 'archlinux-2023.08.01-x86_64.iso' gpg: Signature made Tue 01 Aug 2023 14:19:49 CEST gpg: using EDDSA key 3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C gpg: issuer "pierre@archlinux.org" gpg: key 76A5EF9054449A5C: public key "Pierre Schmitz <pierre@archlinux.org>" imported gpg: key 7F2D434B9741E8AC: public key "Pierre Schmitz <pierre@archlinux.org>" imported gpg: Total number processed: 2 gpg: imported: 2 gpg: Note: third-party key signatures using the SHA1 algorithm are rejected gpg: no ultimately trusted keys found gpg: Good signature from "Pierre Schmitz <pierre@archlinux.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 3E80 CA1A 8B89 F69C BA57 D98A 76A5 EF90 5444 9A5C • rocketmouse@archlinux /tmp/verification_demo $ echo $? 0
3.
• rocketmouse@archlinux /tmp/verification_demo $ pacman-key -v archlinux-2023.08.01-x86_64.iso.sig ==> Checking archlinux-2023.08.01-x86_64.iso.sig... (detached) gpg: Signature made Tue 01 Aug 2023 14:19:49 CEST gpg: using EDDSA key 3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C gpg: issuer "pierre@archlinux.org" gpg: Note: trustdb not writable gpg: Good signature from "Pierre Schmitz <pierre@archlinux.org>" [full] gpg: aka "Pierre Schmitz <pierre@archlinux.de>" [unknown] • rocketmouse@archlinux /tmp/verification_demo $ echo $? 0
Regards, Ralf
One nice thing sourceforge.net does for packages is to have all old versions show their dates in their package names but the current package has latest replacing its date in its package name. Removes confusion as to which package to download that way. With only multiple date possibilities to download something like scripting would be needed to locate current packages and associated verification files for download unless a user would otherwise search directories and have had enough coffee on board for those late night file download sessions. More than once I got the wrong verification files that didn't match a dated package and had to clean the disk and try another download.
On Thu, 2023-08-31 at 20:06 -0400, Jude DaShiell wrote:
I used a flash drive earlier and removed it but now have an /dev/sdb drive with 8 megs size on the computer that remains after power is shut off when power is turned on again.
How do you determine the size? If I connect an USB stick and then run... • rocketmouse@archlinux ~ $ cd Desktop/ • rocketmouse@archlinux ~/Desktop $ mkdir mount_point_usb_stick • rocketmouse@archlinux ~/Desktop $ mount /dev/sdz2001 /home/rocketmouse/Desktop/mount_point_usb_stick/ mount: /home/rocketmouse/Desktop/mount_point_usb_stick: must be superuser to use mount. dmesg(1) may have more information after failed mount system call. ...I missed that the USB stick wasn't mounted, but write something using the "mount point"... • rocketmouse@archlinux ~/Desktop $ echo hallo > /home/rocketmouse/Desktop/mount_point_usb_stick/text.txt ...I'm quite sure it will be there after a reboot, without the USB stick attached, since text.txt was written to the internal SSD. Just an idea!
fdisk and I can double check with du and probably lsblk. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Fri, 1 Sep 2023, Ralf Mardorf wrote:
On Thu, 2023-08-31 at 20:06 -0400, Jude DaShiell wrote:
I used a flash drive earlier and removed it but now have an /dev/sdb drive with 8 megs size on the computer that remains after power is shut off when power is turned on again.
How do you determine the size?
If I connect an USB stick and then run...
• rocketmouse@archlinux ~ $ cd Desktop/ • rocketmouse@archlinux ~/Desktop $ mkdir mount_point_usb_stick • rocketmouse@archlinux ~/Desktop $ mount /dev/sdz2001 /home/rocketmouse/Desktop/mount_point_usb_stick/ mount: /home/rocketmouse/Desktop/mount_point_usb_stick: must be superuser to use mount. dmesg(1) may have more information after failed mount system call.
...I missed that the USB stick wasn't mounted, but write something using the "mount point"...
• rocketmouse@archlinux ~/Desktop $ echo hallo > /home/rocketmouse/Desktop/mount_point_usb_stick/text.txt
...I'm quite sure it will be there after a reboot, without the USB stick attached, since text.txt was written to the internal SSD.
Just an idea!
On Fri, 2023-09-01 at 07:40 -0400, Jude DaShiell wrote:
fdisk and I can double check with du and probably lsblk.
Again, my apologies, assuming the disconnected device is listed by the /dev/ directory after a reboot, what I recommended as an idea is nonsense.
One problem solved. It turns out windows adapters don't work well on linux computers. I had connected my monitor to the computer with an insignia usb adapter and once that got removed this whole problem went away. I plan on doing an archlinux install this weekend and if errors get generated I'll send those along. If no errors get generated, that insignia windows usb monitor adapter was responsible for them in which case no fixes to archlinux iso other than future improvements need be done. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.
On Thu, 2023-08-31 at 18:53 +0200, mpan wrote:
in future please do not paraphrase errors: it really makes helping harder
I have no idea about the setup used by Jude. Jude, assuming that copy & paste shouldn't work that easy, can you take screenshots or record a screen reader and post links to screenshots or recordings of the used commands + the output.
espeak doesn't do screen shots. I'll have to check and see if tee is available on the arch install disk. I can probably save the interesting material to a flash drive then post later on a working operating system where email works. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.
On Fri, 2023-09-01 at 07:38 -0400, Jude DaShiell wrote:
espeak doesn't do screen shots. I'll have to check and see if tee is available on the arch install disk. I can probably save the interesting material to a flash drive then post later on a working operating system where email works.
Yes, redirecting was another thought, I had, too. Don't forget to ensure that stderr is redirected, too ;).
On Fri, 2023-09-01 at 07:38 -0400, Jude DaShiell wrote:
espeak doesn't do screen shots.
Maybe a smartphone or another recorder can be used, to record the audio signal from the speakers.
participants (3)
-
Jude DaShiell
-
mpan
-
Ralf Mardorf