I bumped into the same issue as this topic: Unable to sign VBA with valid Sectigo Code Signing certificate
Basically, I have a Sectigo EV code signing certificate with a USB-stick that I need to plug in in order to sign my code. I am using that for signing my excel add-in in Visual Studio (DLLs) and the .msi file that we build from that with signtool:
signtool sign /tr http://timestamp.comodoca.com /td sha256 /fd sha256 /d Prog2Installer.msi /a C:\Users\hello\source\repos\ME\Prog2\bin\Release\Prog2mInstaller.msi
That works fine, I get a pop-up asking me for my password and it signs ok.
But now I also want to use my certificate to sign my excel/VBA xlsm file. When I plug in my USB key I can select the certificate in VBE (named "Installed by Sectigo Browser extension"), but when I save the file, I get the same feedback as the referenced post:
There is a problem with the digital certificate. The VBA project could not be signed. The signature will be cancelled
I checked the certmgr, can see the certificate there, but can't export as .pfx, only as .cer (so no private keys, as they reside on the USB stick I assume). I also added those 3 timestamp items that were suggested in the referenced post, but still nothing.
Sectigo/Comodo seem to have no clue (tried their helpdesks), I hope that anyone here can advice me what to do to get this to work?
I had a response from Sectigo - who had contacted the certificate token manufacturer. It looks like this is indeed Microsoft's problem - requiring an MD5 hash when signing VBA code - even though that's no longer considered secure.
As a workaround, if you are using Safenet AND if your token still supports MD5, you can make the following registry changes:
Find the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\SafeNet\Authentication\SAC"
Add a new registry key "Crypto"
Add a new string value to this key - "Disable-Crypto"
Give "Disable-Crypto" a value "None"
Then, add the signature to VBA in the usual way. In my case, when saving the file, it asks for the token password three times before completing the save.
Full details - inluding more information about the issue
Unless there is a change to the MD5 requirement for signing VBA code, it will not be possible to sign VBA code at all in the future (i.e. no certificate providers will support it). Therefore, I suggest that people contact Microsoft to urge them to act on this issue.
I had some phone conversations with their helpdesk. My summary of those conversations: it's Microsofts problem... I didn't file anything with MSFT but as I needed a working certificate, I went for the EV code signing for my DLL/Visual studio (works fine) and bought a simple code signing certificate to sign my VBA/Excel. After a bit of fiddling it simply works. So I pay 580 USD/year vs 400 USD/year but have a working solution.
So I'm a Schrodinger Sectigo customer now, being both happy & unhappy at the same time.
I have just gone to https://couchdb.apache.org/ to get the latest CouchDB binary (upgrading from 2.2).
However, the download link redirects me to an organisation called Neighbourhoodie - a CouchDB services & consultancy firm (which was unexpected, but understandable as I know the installations may be served from mirrors).
When I ran the installer I got a warning from Windows that the binary is from an 'Unknown Publisher'.
I can't find a contact point on the CouchDB site to ask a question like this.
The unexpected redirect coupled with the Unknown Publisher have made me nervous - how can I know that it's safe to proceed with the upgrade?
You can verify that the couchdb contributors that signs public releases believed this binary is correct for windows users by comparing the site, sha1 and md5 sums they gave in an issue. Neither a sha1 or md5 alone is secure, but I think it would be exceedingly hard to find an attack that simultaneously works for both.
Also, if you download the gpg signature, binary and the https://downloads.apache.org/couchdb/KEYS you can verify that this signer is the same signer using the same key recognized on the apache download site. Using their trust is similar to tofu, you trust the channel with https and it trusts this key, so now you trust the key on another channel.
On linux/mac this looks like:
(verify you obtain keys over ssl from apache, then:)
$ gpg --import KEYS.txt
...
gpg: key CDE711289384AE37: "**** (CODE SIGNING KEY) <****#apache.org>"
(download a sig and file from official downloads.apache.org site and verify + add your "tofu" trust in this key)
$ gpg --trusted-key CDE711289384AE37 --verify apache-couchdb-3.1.1.tar.gz.asc
(your gpg now trusts this key for new binaries)
$ gpg --verify apache-couchdb-3.1.0.msi.asc
(If the official KEYS file changes you would want to delete this trust and do the same process again:)
$ gpg --delete-key CDE711289384AE37
and windows gpg should look similar, maybe with / in place of --, etc.
I tried to decrypt pgp files somes are getting correctly decrypted but others are still having problem for decryption.
Command which i am using for decryption is :
pgp -z pass_phrase D:\PGP_FILES\file1.pgp -o D:\PGP_FILES\DecryptedFile
Its output :
Pretty Good Privacy(tm) Version 6.5.1
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
File is encrypted. Secret key is required to read it.
Key for user ID: User <mail_id>
1024-bit RSA key, Key ID 0xABC, created date
Key can sign.
And stops after several minutes.
After the decryption is started output file is getting created and also its size is increasing till the end phase but after completion of decryption file is getting deleted automatically.
I am not getting reason behind the problem. So can anybody please help me come out of this situation? What is the exact problem?
I formatted my Windows 7 laptop and in an attempt to have git setup working again, I installed git and source tree application.
I deleted the SSH Key from gitlab and regenerated the key using ssh-keygen. But when I try to add the SSH Key at gitlab, it throws the following exception :
Key is invalid
Fingerprint has already been taken
Fingerprint cannot be generated
Because of this I am unable to clone the git repository from the source tree application since gitlab is unable to authenticate the SSH key.I followed queries at google groups of gitlab but none of them seem to resolve my issue. Is there any workaround or steps to get the SSH key accepted by gitlab?
In my case; the public key i was trying to add was already used with 'work' Gitlab account and i received the said error upon trying to use the same key with 'personal' Gitlab account.
Solution - Add another public key on the same machine and use that with 'personal' gitlab account (both on same machine).
navigate to .ssh folder in your profile (even works on windows) and run command
ssh-keygen -t rsa
when asked for file name give another filename id_rsa_2 (or any other).
enter for no passphrase (or otherwise).
You will end up making id_rsa_2 and id_rsa_2.pub
use the command
cat id_rsa_2.pub
copy and save key in 'personal' Gitlab account.
create a file with no extension in .ssh folder named 'config'
put this block of configuration in your config file
Host gitlab.com
HostName gitlab.com
IdentityFile C:\Users\<user name>\.ssh\id_rsa
User <user name>
Host gitlab_2
HostName gitlab.com
IdentityFile C:\Users\<user name>\.ssh\id_rsa_2
User <user name>
now whenever you want to use 'personal' gitlab account simply change alias in git URLs for action to remote servers.
for example
instead of using
git clone git#gitlab.com:..............
simply use
git clone git#gitlab_2:...............
doing that would use the second configuration with gitlab.com (from 'config' file) and will use the new id_rsa_2 key pair for authentication.
Find more about above commands on this link
https://clubmate.fi/how-to-setup-and-manage-multiple-ssh-keys/
Gitlab can use your ssh-key in another account of your past projects for somehow - so, easiest way to solve this problem is to create new ssh-pair, add it to ssh-agent and add id_rsa2.pub to your gitlab account.
$ ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
When it ask:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<NAME>/.ssh/id_rsa):
Please enter /home/<NAME>/.ssh/id_rsa2
$ ssh-add ~/.ssh/id_rsa2
Make sure to cut away everything at the end of the base64 encoded string.
Also remove all newlines so the string contains no newlines.
This did the trick for me.
I got the same error because I already added this key to another account in gitlab.
I tried everything already suggested and nothing worked. What ended up working for me was to copy the public key using a command rather than from a text editor (nano in my case):
pbcopy < ~/.ssh/id_rsa.pub
replacing, if necessary, id_rsa with my specific key name. The above command works on OSX. Other systems require a different command, and they are listed on the following page: http://doc.gitlab.com/ce/ssh/README.html.
In my case I already had the public key added on another repo.
Fix:
On the same GitLab page (Settings -> Repository -> Deploy Keys)
Scroll down and click to the TAB "Privately accessible deploy keys"
Find your "Deploy key" in the list and click the Enable button
Then you are good to go.
My SSH key was stored in an old Gitlab account, I removed it and problem solved.
Text editor could be the problem. Try to open key file with Notepad, not Notepad++.
Also add "ssh-rsa " at the beginning of the key.
Make a New Key
None of the above solutions worked for me so I backed up my old key and created a new one.
https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
#osx10.12.6
In my case, my public key must have somehow been attached to a specific repository.
I went back and deleted two old repositories and after that it allowed me to add the public key to my GitLab account without any problems.
Add new ssh key
The pervius ssh key probabley use by another user . When somone else use a ssh key you must get this error dint worry create a new ssh key and use theme.
In the same gitlab setting page where you tried to add the deploy key scroll down a little bit and you shall find a tab called "Privately accessible deploy keys". Click it and you shall find the key you tried to add listed there. Just click "Enable" from next to it and it would work !
If all these suggestions don't work:
First of all - don't deal with security keys being exhausted or in a hurry, not to do silly mistakes (my case).
Secondly - copy as GitLab deploy key public-key, not the private one (my case as well, despite well understand oh how keys work, just being in a hurry).
In my case, I have not added an existing Deploy key to any other project before, and I am was not a member of any project.
In order to be able to enable the deploy key for a new project, you need to add yourself as a member to a project where this key has already been enabled.
Then in the New Project-Settings-Repository-Deploy keys-Privately accessible deploy keys list, you will see this key and the Enable button.
The answer is found in this documentation
https://gitlab-docs.creationline.com/ee/user/project/deploy_keys/
In the Privately accessible deploy keys tab, you can enable a private
key which has already been imported in a different project. If you
have access to these keys, it's because you have either:
Previously uploaded the keys yourself in a different project.
You are a maintainer or owner of the other project where the keys were imported.
But if you have GitLab admin profile, it's enough even to have "User" privileges as a member for the project.
I configured msmtp with my gmail account.
I obviously want to avoid writing my password in plaintext format in the config file.
Luckily enough msmtp offer the option passwordeval which can be used to obtain the password from the output of an an executable.
The question is: how should I use it?
I found here the following suggestion:
passwordeval gpg -d /some/path/to/.msmtp.password.gpg
That doesn't make much sense to me: if someone is able to access my config file he will certainly manage to run such a command and obtain the password from gpg.
So I believe I'm left with the only option of obfuscating the password within the binary executable even if I read almost everywhere that this is bad!
My impossible-to-hack implementation is: if the sendmail process is running output the correct pass, otherwise give a fake pass.
Your suggestions?
Other (more secure) tricks different from storing the pass in the binary file?
From Sukima's comment:
The reason gpg -d works is because it requires the private key of the person the file is encrypted to. So just placing that encrypted file in the public it is still encrypted an only one person (the one with the secret key) can decrypt it. It is assumed that the secret key is locked up on the user's machine and not leaked. It also assumes that they have not setup any agents which cache the unlock password while a hacker has direct access to the same machine. All of which is highly unlikely in 99% of all attacks.
There is not a standard solution on how to save credentials with the constraint of
having to use the credentials in plain text later
and in an unattended way
on a system which is not completely controlled by you (if it is you just set appropriate rights on the files holding the secrets)
You have several solutions, none solves perfectly your problem:
encrypt your credentials in a symmetric way: you need to input the key to decrypt them
encrypt in an asymmetric way: you need to provide your private key, which must be stored somewhere (unattended approach) or keyed in
obfuscate: as you mention, this only protects from some population
get it from somewhere else - you need to identify a way or another your system
You need to take into account which risk is acceptable and go from there.