Hello stackoverflow World,
I'm investigating using the miniconda package manager for the first time.
I downloaded the files from here: https://docs.conda.io/en/latest/miniconda.html
I'm on a windows machine so downloaded the following file:
As I am hoping is obvious from my title, the check sum that my machine produces using the Windows certUtil -hashfile function produces a different check sum.
Now, my main issue is what to do now...!
Do I run screaming to the hills burning all my IT kit as I go, or is there a way to get to the bottom of this?
Thanks in advance
So interestingly, using the PowerShell approach rather than the cmd line, as specified in the miniconda download reference did result in a matching Hash key.
I thought that these were supposed to be independent of the program used to unpack the HASH...?
hash is not a universally defined algorithm:
A hash function is any function that can be used to map data of arbitrary size to fixed-size values (https://en.wikipedia.org/wiki/Hash_function)
So when you use a program to hash a file and want to compare it to a published value, you must make sure that you are using the same hash function. In your case, the miniconda download page already clarifies that it is a SHA256 hash, which you need to specify when calling certutil.
Proof:
Without specifying the hash function (SHA1 is used and - as expected - produces a different hash value):
certutil -hashfile Miniconda3-latest-Windows-x86_64.exe
SHA1 hash of Miniconda3-latest-Windows-x86_64.exe:
0b553f6b77926db707c4406cafc612d74301b24e
CertUtil: -hashfile command completed successfully.
Specifying the correct function produces the right hash value:
certutil -hashfile Miniconda3-latest-Windows-x86_64.exe SHA256
SHA256 hash of Miniconda3-latest-Windows-x86_64.exe:
6013152b169c2c2d4bcd75bb03a1b8bf208b8545d69116a59351af695d9a0081
CertUtil: -hashfile command completed successfully.
Related
I'm a beginner in cryptography and I was deciphering a list of md5 hashes using hashcat 6.2.5,
the problems that I faced were:
my cmd didn't recognize hashcat64.exe as a command but accepted hashcat.exe as a command
my text docs don't visually show the .txt extension but are indeed .txt files when checked with properties or path
decoding a list of hashes, I used the -m 0 and -a 0 command but when executed, gave the "token exception length, no hashes loaded" error.
how to resolve this issue?
I want to implement a function which monitor a directory and perform some action when a new file is downloaded from the Internet, but found it difficult to determine if the file is completely downloaded, is there a way to do that?
Usually tools that show the hash of a file will give the state of a file - this should be compared to the hash of another file - if identical then we know the file has downloaded successfully.
md5 (native to bsd) is available - but is only practical on a local file -
If you are retrieving the remote file via HTTP , then there is no way to get the hash of the file without downloading it first (whether it is to STDOUT or piped to file , using wget -O- or curl )
If the file host has a second file that contains the md5 hash of the file being downloaded - then a comparison of the locally downloaded hash is comparable to the hash provided by the file provider.
To do anything more swish will require a comprehensive program to be written - such as the combination of this question and accepted answer :
Python Compare local and remote file MD5 Hash
Besides MD5, there is a simple way to do this:
Partially downloaded file usually has a temporary filename, and it will be renamed to original filename after fully downloaded. You can make your program to ignore or monitor only certain filename extensions.
Since macOS 11.3 broke my Perl script which I have been using to generate Sparkle appcasts for the last 12 years, I decided to instead start using the generate_appcast tool which has since been provided with Sparkle. Invoking generate_appcast with no arguments, I get some brief documentation which I interpret to mean that I should provide two arguments:
a -f followed by the path to my Sparkle private key file
the path to a directory of several recent versions of my app, all zipped
So I created a new directory and copied zip archives of the three most recent versions of my app into it. Those are the .zip archives, notarized by Apple, which I upload to my site for users to download.
Then I ran this command:
Air2:~ jk$ generate_appcast -f /path/to/My_Sparkle_priv.pem /path/to/directory/of/zips
The result:
Warning: Private key not found in the Keychain (-25300). Please run the generate_keys tool
Error generating appcast from directory /path/to/My_Sparkle_priv.pem
Error Domain=NSCocoaErrorDomain Code=256 "The file “My_Sparkle_priv.pem” couldn’t be opened." UserInfo={NSUserStringVariant=(
Folder
), NSURL=file:///path/to/My_Sparkle_priv.pem/, NSFilePath=/path/to/My_Sparkle_priv.pem, NSUnderlyingError=0x13a637e10 {Error Domain=NSPOSIXErrorDomain Code=20 "Not a directory"}}
Apparently it is not recognizing the key file I provided, and also oddly implies that it expects a directory instead of a regular file. In the brief documentation, there is an example marked [DEPRECATED] which omits the -f before the path to the key file, so I tried that but got the same result. I also tried putting the path to the zips first, but that result was even worse.
My key file is, I think, a pretty standard .pem text file that begins with the line -----BEGIN DSA PRIVATE KEY----- followed by 1133 ASCII characters, etc.
Where did I miss the boat?
Astonishingly, this seems to be due to an obvious programming error in the Sparkle generate_appcast Swift source code. In attempting to remove elements indexed N and N+1 from an array of command-line arguments, the code removes element N, and then removes element N+1, which of course removes elements N and N+2 instead. After I fixed this programming error, the problem is solved.
After I do some more head-scratching and maybe consulting with others smarter than me, I shall submit a pull request or whatever to the Sparkle project next week.
I have a digital cert bought from a third-party CA and I wanted to use it to sign software with a large number of library files/packages (.bpl). However, signing them one by one takes a lot of time and I am wondering is there any ways to allow me to use a shorter time to sign all the files?
The current command I am using to sign the files is as below:
signtool.exe sign /tr http://timestamp.sectigo.com /td sha256 /fd sha256 /a "Insert_path_to_the_file_you_wish_to_sign"
I was signing multiple files using the signtool in a parallel loop. It seemed to work, but I noticed that our certificate provider (DigiCert) recommends that you avoid concurrent requests.
https://dev.digicert.com/best-practices/
So instead, I'm now using the signtool in one command - passing in all the files in one command line argument. According to Microsoft's documentation, you can use an '|' between each file.
signtool [command] [options] [file_name | ...]
https://learn.microsoft.com/en-us/dotnet/framework/tools/signtool-exe
And maybe useful for someone, Digicert's DigiCertUtil uses '*' between each file.
Filenames is a list of files to be code signed. To specify more then
one file, seperate each filename or file path with the asterisk
character *. Enclose the file path with quotes if it contains spaces.
example: DigiCertUtil.exe sign /kernelDriverSigning
"example.exedriver.sys" example: DigiCertUtil.exe sign /sha1
"054D9508B364A02A068FA5C6153847B6" "example.exedriver.sys"
Based on the recommendation to avoid concurrent requests, I'm assuming that even when specifying multiple files in either the SignTool or DigiCertUtil, the files will still be signed one at a time.
I use sha256 hash value to encrypt a password( no matter digit form or char form ).
when I unzip the password-protected file, I can use at least two different hash to unzip my file -- it occurs a Hash collision. Although there is no searching point out this situation, I know md5 and sha-1 have hash collision. so what is the problem?
Case1: I use 5566 sha256 hash zip my file
zip -P be41b7f1fa56ba2b0582910053c86cf6ee7e311efc51300220df0918bb9a287b abc.zip abc
Reference Sha256(0138) = 687d579d0992a7895190ad126ba8051704753bdc85d52481a83da4670e2321d7
Reference Sha256(5566) = be41b7f1fa56ba2b0582910053c86cf6ee7e311efc51300220df0918bb9a287b
However, apart from 5566 hash value, I also can use 0138 hash value to unzip this file. The following code both success in file extraction.
unzip -P 687d579d0992a7895190ad126ba8051704753bdc85d52481a83da4670e2321d7 abc.zip
unzip -P be41b7f1fa56ba2b0582910053c86cf6ee7e311efc51300220df0918bb9a287b abc.zip
Case2: I can use 'daniel' sha256 hash and 'pivate' sha256 hash to unzip a file.
Thank you for your attention. Hope someone can solve my problems.
I am doing a password brute-forcing assignment, and I cannot get the correct cracked password
because of the above problem.
[Solved]
empty zip files may lead to problems in unzip.