osslsigncode verify VirtualBox-7.1.0-164728-Win.exe: Functional. osslsigncode verify vc_redist.x64.exe: Broken. Why? How to fix? Full logs below. Debian 12. ---- Functional:

osslsigncode verify VirtualBox-7.1.0-164728-Win.exe

Current PE checksum   : 0698F8DE
Calculated PE checksum: 0698F8DE

Signature Index: 0  (Primary Signature)
Message digest algorithm  : SHA256
Current message digest    : 219D775E1F63FD2734FDB97D7EE67A17488B0E18B9A294114F7E17D8834B597F 
Calculated message digest : 219D775E1F63FD2734FDB97D7EE67A17488B0E18B9A294114F7E17D8834B597F 

Signer's certificate:
        Signer #0:
                Subject: /C=US/ST=California/L=Redwood City/O=Oracle America, Inc./CN=Oracle America, Inc.
                Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
                Serial : 060E2F8F9E1B8BE518D5FE2B69CFCCB1
                Certificate expiration date:
                        notBefore : Mar  9 00:00:00 2023 GMT
                        notAfter : Mar 11 23:59:59 2025 GMT

Number of certificates: 2
        Signer #0:
                Subject: /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
                Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Trusted Root G4
                Serial : 08AD40B260D29C4C9F5ECDA9BD93AED9
                Certificate expiration date:
                        notBefore : Apr 29 00:00:00 2021 GMT
                        notAfter : Apr 28 23:59:59 2036 GMT
        ------------------
        Signer #1:
                Subject: /C=US/ST=California/L=Redwood City/O=Oracle America, Inc./CN=Oracle America, Inc.
                Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
                Serial : 060E2F8F9E1B8BE518D5FE2B69CFCCB1
                Certificate expiration date:
                        notBefore : Mar  9 00:00:00 2023 GMT
                        notAfter : Mar 11 23:59:59 2025 GMT

Authenticated attributes:
        Message digest algorithm: SHA256
        Message digest: 780A2C240E94C6A520FBA4EBA7ADC02D5DB11B0F223CD3F202A4F11A56F73A7A 
        Signing time: N/A
        Microsoft Individual Code Signing purpose

The signature is timestamped: Sep  6 22:12:04 2024 GMT
Hash Algorithm: sha256
Timestamp Verified by:
                Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
                Serial : 0544AFF3949D0839A6BFDB3F5FE56116

CAfile: /etc/ssl/certs/ca-certificates.crt
TSA's certificates file: /etc/ssl/certs/ca-certificates.crt
CRL distribution point: http://crl3.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl 
TSA's CRL distribution point: http://crl3.digicert.com/DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crl 

Timestamp Server Signature verification: ok
Signature verification time: Sep  6 22:12:04 2024 GMT
Signature verification: ok

Number of verified signatures: 1
Succeeded

---- Broken:

osslsigncode verify vc_redist.x64.exe

Current PE checksum   : 0187CD76
Calculated PE checksum: 0187CD76

Signature Index: 0  (Primary Signature)
Message digest algorithm  : SHA256
Current message digest    : 870E96D39FD03180C74AE4BCC1C4B6203AF36AABDAC37210773C127F37393036 
Calculated message digest : 870E96D39FD03180C74AE4BCC1C4B6203AF36AABDAC37210773C127F37393036 

Signer's certificate:
        Signer #0:
                Subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation
                Issuer : /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Code Signing PCA 2011
                Serial : 3300000403BDD5955D0F3B18AD000000000403
                Certificate expiration date:
                        notBefore : Sep 12 20:11:13 2024 GMT
                        notAfter : Sep 11 20:11:13 2025 GMT

Number of certificates: 2
        Signer #0:
                Subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation
                Issuer : /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Code Signing PCA 2011
                Serial : 3300000403BDD5955D0F3B18AD000000000403
                Certificate expiration date:
                        notBefore : Sep 12 20:11:13 2024 GMT
                        notAfter : Sep 11 20:11:13 2025 GMT
        ------------------
        Signer #1:
                Subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Code Signing PCA 2011
                Issuer : /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2011
                Serial : 610E90D2000000000003
                Certificate expiration date:
                        notBefore : Jul  8 20:59:09 2011 GMT
                        notAfter : Jul  8 21:09:09 2026 GMT

Authenticated attributes:
        Message digest algorithm: SHA256
        Message digest: C21A9171ECEC5F60ADFB1DDFF81B447D8B810D6A893F604E7C3D50849E3719DD 
        Signing time: N/A
        Microsoft Individual Code Signing purpose
        URL description: http://www.microsoft.com 
        Text description: Microsoft Visual C++ 2015-2022 Redistributable (x64) - 14.42.34433

The signature is timestamped: Oct 29 12:03:40 2024 GMT
Hash Algorithm: sha256
Timestamp Verified by:
                Issuer : /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Time-Stamp PCA 2010
                Serial : 33000001F91F678D75ABA4F1B10001000001F9

CAfile: /etc/ssl/certs/ca-certificates.crt
TSA's certificates file: /etc/ssl/certs/ca-certificates.crt
CRL distribution point: http://www.microsoft.com/pkiops/crl/MicCodSigPCA2011_2011-07-08.crl 

CMS_verify error
4049E3FCAC7E0000:error:17000064:CMS routines:cms_signerinfo_verify_cert:certificate verify error:../crypto/cms/cms_smime.c:289:Verify error: unable to get local issuer certificate
Timestamp Server Signature verification: failed

PKCS7_verify error
4049E3FCAC7E0000:error:10800075:PKCS7 routines:PKCS7_verify:certificate verify error:../crypto/pkcs7/pk7_smime.c:295:Verify error: unable to get local issuer certificate
Signature verification: failed

Number of verified signatures: 1
Failed
zsh: exit 1     osslsigncode verify vc_redist.x64.exe

I've recently finished up Linux Device Drivers and have had moderate success writing the device (as opposed to host) side code for a dev board. For most applications, indeed almost all applications in the embedded world, it is sufficient to pose as a serial device. The ACM driver gives me some idea of what to do in the event that it *isn't* sufficient. However, my impression is that USB drivers tend to be very buggy, especially from vendors trying to go "off the beaten path". (My heart goes out to all the digital artists whose drawing tablet drivers break every couple months) In an effort to not be that guy, I'm curious what kinds of verification options are available on Linux. I had the idea of a "dummy" USB kernel driver whose job is to bind to a specific device and check it for common issues; e.g. non-compliant timing, weird power state behavior, deadlocks, performance. Does such a thing exist out there? I'm aware of the company Totalphase, which makes tools that can verify the physical (cable) layer, but I haven't found anything for the software on either side of said cable.

Our postfix setup uses recipient address verification. Obviously, postfix uses a special email address for this process, defined right here. $ /usr/sbin/postconf | grep double_bounce_sender address_verify_sender = $double_bounce_sender double_bounce_sender = double-bounce Last week we got a problem with this setup, as our smtp asked the target smtp about the recipient address, the target smtp on the other hand, asked our smtp, whether double-bounce@mydomain.com is valid, which it neglected. So, that email could not be delivered, although both the original sender and the recipient are valid email addresses. Now, I have different options: * deactivate address verification * create an alias for double-bounce@mydomain.com, so it gets valid * set another valid email address/alias as double-bounce address I can't foresee the outcome of these actions. Any thoughts?

I want to verify the CAN interfaces on my embedded system. It has two can ports: can0 and can1. I bring them both up with the following sequence: # ip link set can0 type can bitrate 1000000 dbitrate 2000000 fd on # ip link set can0 up # ip link set can1 type can bitrate 1000000 dbitrate 2000000 fd on # ip link set can1 up I hooked them up to each other (CANHCANH, CANLCANL & GNDGND) with termination resistors on each side after the trabnsceivers. Now when I want to send traffic out on can0 and dump rthe incoming traffic on can1. I started candump -c -a any while I invoke:

# cansend can0 01a#11223344AABBCCDD

But after this, I get a bunch of kernel errors that look like: [ 1506.337694] rcar_canfd 10050000.can can0: ch erfl 401 txerr 128 rxerr 0 [ 1506.337702] rcar_canfd 10050000.can can0: Bus error [ 1506.337707] rcar_canfd 10050000.can can0: ACK Error Appears like 128 stands for CAN_ERROR_PASSIVE_THRESHOLD which indicates that about which I read: > **Error Passive**: In this state, the CAN node is still able to transmit data, but it now raises 'Passive Error Flags' when detecting > errors. Further, the CAN node now has to wait for an extra 8 bits (aka > Suspend Transmission Time) in addition to the 3 bit intermission time > before it can resume data transmission (to allow other CAN nodes to > take control of the bus) source: https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial#:~:text=A%20CAN%20node%20enters%20the,if%20the%20TEC%20exceeds%20255 There's nothing showing with candump, though. The above messages show up in dmesg. But I still can see data on the CAN lines (with a scope). What do the errors mean, how can I address them and how can I actually see data with candump?

A major goal of open source is being able to audit/verify the software you run. But the moment we use that software hosted by a third-party we need to trust them.. If I ran an OSS service on a Linux box that I wanted to make 100% transparent, is there a way for me to offer _anyone_ to verify the box is running what I say it is running? Some ideas that come to mind: - have a read-only user that can ssh into the box and execute exactly one command to verify the list of installed packages - use NixOS which uses deterministic installs (I think called generations), could such an "audit" user access the box and cryptographically verify installed packages and configurations? Are there any tools that can help with this? Not an expert :) Any suggestions more than welcome.

I have been using the following command so far to verify my /etc/fstab: sudo findmnt --verify Unfortunately, it spills out warnings for each unreachable disk (which I don't care about) and I have not found a flag to change that. Any clever tip to get rid of these warnings or an alternative standard tool?

I've renewed and imported my old self-generated GPG certificate. After setting the new expiration date I've uploaded my cert using gpg --keyserver pgp.mit.edu --send-keys Receiving a test mail, Evolution reports that the mail contains a valid certificate that couldn't be verified. I'm wondering how that should work. Following tutorials on the web, I could create any certificates for arbitrary mail addresses and just publish them on some cert server. So how can I setup a _verified_ certificate accepted by any mail receiver? Is this even possible for accounts on public email providers, e.g. some-account@gmail.com?

Warning info "This key is not certified with a trusted signature!" when to verify apache : wget https://downloads.apache.org/accumulo/1.10.2/accumulo-1.10.2-bin.tar.gz wget https://downloads.apache.org/accumulo/1.10.2/accumulo-1.10.2-bin.tar.gz.asc wget https://downloads.apache.org/accumulo/KEYS gpg --import KEYS gpg --verify accumulo-1.10.2-bin.tar.gz.asc accumulo-1.10.2-bin.tar.gz An error info occurs: gpg: Signature made Tue 08 Feb 2022 11:04:00 PM HKT gpg: using RSA key 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D gpg: Good signature from "Christopher L Tubbs II (Christopher) " [unknown] gpg: aka "Christopher L Tubbs II (Developer) " [unknown] gpg: aka "Christopher L Tubbs II (Developer) " [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: 8CC4 F8A2 B29C 2B04 0F2B 835D 6F0C DAE7 00B6 899D I want to trust it fully: gpg --edit-key 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub rsa4096/6F0CDAE700B6899D created: 2012-10-13 expires: 2024-01-12 usage: SC trust: full validity: unknown sub rsa4096/2FFC0085C23D3DA9 created: 2012-10-13 expires: 2024-01-12 usage: E sub rsa4096/4417A0C14245D003 created: 2013-04-28 expires: 2024-01-12 usage: A [ unknown] (1). Christopher L Tubbs II (Christopher) [ unknown] (2) Christopher L Tubbs II (Developer) [ unknown] (3) Christopher L Tubbs II (Developer) gpg> trust pub rsa4096/6F0CDAE700B6899D created: 2012-10-13 expires: 2024-01-12 usage: SC trust: full validity: unknown sub rsa4096/2FFC0085C23D3DA9 created: 2012-10-13 expires: 2024-01-12 usage: E sub rsa4096/4417A0C14245D003 created: 2013-04-28 expires: 2024-01-12 usage: A [ unknown] (1). Christopher L Tubbs II (Christopher) [ unknown] (2) Christopher L Tubbs II (Developer) [ unknown] (3) Christopher L Tubbs II (Developer) Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 4 pub rsa4096/6F0CDAE700B6899D created: 2012-10-13 expires: 2024-01-12 usage: SC trust: full validity: unknown sub rsa4096/2FFC0085C23D3DA9 created: 2012-10-13 expires: 2024-01-12 usage: E sub rsa4096/4417A0C14245D003 created: 2013-04-28 expires: 2024-01-12 usage: A [ unknown] (1). Christopher L Tubbs II (Christopher) [ unknown] (2) Christopher L Tubbs II (Developer) [ unknown] (3) Christopher L Tubbs II (Developer) gpg> quit Then to verify again: gpg --verify accumulo-1.10.2-bin.tar.gz.asc accumulo-1.10.2-bin.tar.gz gpg: Signature made Tue 08 Feb 2022 11:04:00 PM HKT gpg: using RSA key 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D gpg: Good signature from "Christopher L Tubbs II (Christopher) " [unknown] gpg: aka "Christopher L Tubbs II (Developer) " [unknown] gpg: aka "Christopher L Tubbs II (Developer) " [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: 8CC4 F8A2 B29C 2B04 0F2B 835D 6F0C DAE7 00B6 899D How can suppress the warning info when to verify apache ?

I want to make a fresh new copy of a large number of files from one local drive to another. I've read that rsync does a checksum comparison of files when sending them to a remote machine over a network. 1. Will rsync make the comparison when copying the files between two local drives? 2. If it does do a verification - is it a safe bet? Or is it better to do a byte by byte comparison?

Scenario: Using Linux shell to back up a directory of many sub files and compressing the data with ‘tar -cvpJf filename.tar /savedir/’. Goal: Using shell — checksum or validate the newly created ‘.tar’ against the original directory. Limitations: Solution cannot involve downloading 3rd party support libraries. User cannot be part of the process. Comments: Basically, I am wondering if there is a tar flag I am missing that will validate upon creation of the tar, or maybe I can pipe the tar into some process?

I have a cloud setup with 6 front end computers using Apache. I installed a new SSL certificate. Now I want to verify that all the machines have the certificate. The problem is if I just use https://www.example.com/ the IP address is going to be randomly assigned and I will be able to verify one of the computers. The DNS returns one of the 6 IP addresses in a simple form of round robins. I know how to force the IP address on my computer using the /etc/hosts file, but I am hoping that there could be an easier way to do that. Like using curl and specifying the IP address along the domain name? I prefer to have it as command line (wget, curl, open_ssl...) so that way I can write a script and verify the date of the certificate in an automated way and make sure all the computers present the correct certificate. The command should download the certificate so it can be checked on my client computer.

This is a question about the interaction between a process and the linux kernel. This is in the context of a formal proof, so the setting may seem a bit weird. Suppose I have a program, loaded from an ELF file in the usual way, that cannot write to its own code segment nor its data segment in let's say "unapproved" ways, and it also cannot issue unapproved system calls, but it can write to any other position in memory (which is to say, it is allowed to issue a write to any location). Is this safe? It is okay if the program accesses an unmapped page, because this will cause a segmentation fault, which will cause the program to visibly exit with an error. (The concern is whether the program can *not* exit and instead do unapproved things.) Besides a segfault, what kinds of effects are possible if you write to random places in memory? For instance, is there any MMIO or secret alternative syscall / kernel communication mechanism sitting in a process-visible page? The statement I would like to be true is the following: If memory addresses [x-y] (the code & data of the program) contain value V and a write is issued to a location outside [x-y], then either the process exits with an error code, or the memory at [x-y] still contains V (and all other process invariants still hold: the process is still in user mode, the kernel has not created any MMIO mappings, etc.). * If the page mapping contains a mirror outside [x-y], it may be possible for a write outside [x-y] to succeed and alter data in [x-y]. But I don't think the kernel normally produces these kinds of pages unless you ask it to. * There is a mapped vDSO page somewhere in virtual memory, but writing to it should be fine since I don't need these functions. The main reason I want to be able to write to memory is to simplify stack handling. Most compilers produce no stack bounds checking and linux imperfectly protects against stack overflow using a guard page. I believe it is possible to circumvent the guard by allocating a very large array on the stack and accessing a well chosen index into it. If this accesses the data page of the application the program will surely break, so this at least needs protection, but I don't know what else needs protection as well. How near can heap allocations (mmapped pages and sbrk) get to the stack? It seems like it should be possible to get a standards conformant C program to violate the abstract semantics using a "stack smashing" technique like this (using either a large constant size array or alloca to allocate huge amounts of memory without telling the kernel, then using malloc to acquire memory inside the large array because the kernel doesn't know it's already allocated, and then writes to the array can change the contents of the malloc'd region).

Is there a simple command to verify the password of the current user? The command $ su -c true $(id -nu) suffices for non-root users. However a root user doesn’t need to verify his identity when using su. Is there an alternative command with which a root user can safely and simply verify that the root password he remembers is still correct? I use a desktop linux distribution, Arch Linux to be particular.

I am running Devuan Jessie. I want to install another Devuan Ascii from scratch. So I downloaded: - https://files.devuan.org/devuan_ascii/installer-iso/devuan_ascii_2.0.0_amd64_netinst.iso - https://files.devuan.org/devuan_ascii/installer-iso/SHA256SUMS - https://files.devuan.org/devuan_ascii/installer-iso/SHA256SUMS.asc - https://files.devuan.org/devuan_ascii/devuan-devs.gpg - Update: it is now available at https://files.devuan.org/devuan-devs.gpg But I found no way to authenticate devuan-devs.gpg. Other distros like Debian or Ubuntu or similar [allow me to verify the ISO](https://github.com/hilbix/download-debian) from an existing previous version. But for Devuan, I did not find any way: tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --verify SHA256SUMS.asc gpg: assuming signed data in `SHA256SUMS' gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F gpg: Can't check signature: public key not found tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --no-default-keyring --keyring /usr/share/keyrings/devuan-archive-keyring.gpg --verify SHA256SUMS.asc gpg: assuming signed data in `SHA256SUMS' gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F gpg: Can't check signature: public key not found tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --no-default-keyring --keyring /usr/share/keyrings/devuan-keyring.gpg --verify SHA256SUMS.asc gpg: assuming signed data in `SHA256SUMS' gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F gpg: Can't check signature: public key not found tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --keyring ../devuan-devs.gpg --verify SHA256SUMS.asc gpg: assuming signed data in `SHA256SUMS' gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F gpg: Good signature from "Vincenzo (KatolaZ) Nicosia " gpg: aka "Vincenzo Nicosia (KatolaZ) " gpg: aka "Vincenzo Nicosia (KatolaZ) " gpg: aka "KatolaZ " gpg: aka "Enzo Nicosia " gpg: aka "Enzo Nicosia -- KatolaZ " 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: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F As the "key is not certified", there is no indication that the key is not fake. **How can this broken trust chain be fixed?** https://devuan.org/os/documentation/dev1fanboy/general-information does not solve this riddle either. Notes: devuan-devs.gpg probably is not fake. However this assumption does not help. There must be some way to ensure, it is not fake. The initial Hen-Egg problem is already solved, as Devuan (Jessie) already runs at my side. There certainly is some better way to authenticate Ascii's ISO than to upgrade Jessie to Ascii. Right?

I've just downloaded a dataset made available through BitTorrent and (at length) transferred it to my home PC. Now I want to validate that nothing's been corrupted along the way. Unfortunately, the source of the dataset only provides magnet hashes, not .torrent files - which I've learned is where the checksum information is. Is there a way I can look up a particular magnet link in DHT, retrieve the metadata for the torrent from the BT network, and save said metadata into a .torrent file so I can then use it for local verification? I realize I could also just fire up a BitTorrent client on my home internet connection, but I've heard too many scary stories involving legitimate/scientific/etc data and lawyers etc to want to do that. (Long-tail/edge-case FUD, maybe, but still.) (FWIW, OpenVPN/WireGuard and then locally-based BitTorrent are squarely on the agenda once I master per-process default routing on Linux.)

I would like to have chron run my updates periodically and I have been told that the command: apt-get dist-upgrade -y should accept the updates. My concern is that numerous times when manually updating I have run into verification failures and I only wish to automate this process if I am sure that packages with verification issues are not installed. Can anyone confirm that -y will not respond "yes" to the prompt "proceed without verification"? I am ideally hoping for a pretty definitive reference and/or a way for me to test this myself. Thanks.

I am trying to validate a drive that supports secure erase in multiple formats. The format is specified in a vendor specific ATA-8 packet. Our technician has solved the issue quite ingeniously by using the protocol tester drivemaster to create a packet "close" to the one needed and then using the error injection function of a SATA analyzer to modify the packet to the correct format. Now the customer is asking for a Linux utility so that they can test the functionality. I would of course prefer a more straight forward method to test vendor specific commands in the future as well. In general I was wondering if there is a utility in Linux that I could use for drive validation on drives by exercising the protocol directly (ATA, SATA etc.). If this type of support is built into a scripting language (python or perl etc.) then maybe just a little advice as to what language has the best support under Linux for this type of effort. That would save me time researching the best path to take. Thanks, Brian

I am looking to create a script - a linux or a python scrip so that it can create the following things for me as well as Verify the files for me which are copied from a folder. I Have two folders: FolderA has 300 .xls files - This folder is missing some files which are in folder B currently. FolderB has 500 .xls files I want to copy select few 100 files from Folder B to folder A. Then want the script to verify that all the files currently residing now in folder A(should be 400 now after copying 100 files from B) also exist in folder B. Then I want the script to zip all these files separately as its own bzip2 file. Basically there will be 400 bzip2 files(one for each excel) in the end when the process is completed.

Is there a standard method for searching and importing a pgp key using curl or wget? I was going through verifying the download with a gpg signed shasum256 file and encountered the problem of trying to verify the gpg fingerprint. So the standard method is to use gpg --recv-key KEYID that is shown when gpg --verify .asc is run, to auto import the public key from the public synchronizing key servers. But gpg now runs as an agent, and uses dirmngr to mediate this transfer. Unfortunately, dirmngr has never been able to honour the use of web proxies and so i'm left with trying to search and download using a web service and curl. Doing this using a pool of key servers, results in added assurance that the keyfile you're downloading is legitimate across this pool. But this can be also be done if the user downloads the keyfile using https across multiple managed key service providers and verifies that the keyfiles are similar across board. So are there sites with rest endpoints that i can call with just the keyid and get nice ascii armored results?

PureOS has SHA256 verification of download, but I've heard that SHA isn't so secure. Do they sign their files or provide associated .sig files? And is it true that that would be more secure?