Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gpg --verify is insecure for verification of --clearsigned files #95

Open
adrelanos opened this issue Jan 11, 2015 · 8 comments
Open

gpg --verify is insecure for verification of --clearsigned files #95

adrelanos opened this issue Jan 11, 2015 · 8 comments

Comments

@adrelanos
Copy link
Collaborator

gpg --verify is insecure for verification of --clearsigned files. Counter intuitive. But gpg --decrypt should be used instead.

Hard to explain with words. But code and output talks. See:
https://gist.github.com/adrelanos/defdf9d693c2726514fd

Line in question:
https://github.com/martincmelik/Securix-Linux/blob/14e4fd445235e4bf384fd8ffb65e1c43d7bfe9ac/securix-install/install.sh#L823

adrelanos pushed a commit to adrelanos/Securix-Linux that referenced this issue Jan 11, 2015
- fixed check gpg before sha512 martinholovsky#94
- fixed gpg --verify is insecure for verification of `--clearsign`ed files, use gpg --decrypt instead martinholovsky#95
- fixed no need to download unsigned stage3-amd64-hardened-20150108.tar.bz2.DIGESTS when you download `--clearsign`ed stage3-amd64-hardened-20150108.tar.bz2.DIGESTS.asc martinholovsky#96
@adrelanos adrelanos changed the title gpg --verify is insecure for verification of --clearsigned files, use gpg --decrypt instead gpg --verify is insecure for verification of --clearsigned files Jan 13, 2015
@adrelanos
Copy link
Collaborator Author

Yet to be solved. Updated the title and description of this ticket.

@adrelanos
Copy link
Collaborator Author

See this thread "Are there cases where gpg --verify will exit 0, even if verification failed?":
http://lists.gnupg.org/pipermail/gnupg-users/2015-January/052212.html

They seem to disagree? But we should take Werner Koch seriously.

Werner Koch:

On Wed, 14 Jan 2015 14:40, dkg@fifthhorseman.net said:

gpg does use the return code to indicate failure of signature
verification.

But recall that success does not mean that the signature is good.
Check the status output or use gpgv.

http://lists.gnupg.org/pipermail/gnupg-users/2015-January/052228.html

@adrelanos
Copy link
Collaborator Author

I still don't know specific cases, but Werner Koch is very clear about this.

Werner Koch:

Do you mean, for example, the signature could be valid, but the key that
signed it could be revoked and gpg would still exit 0?

Sure. It is just to complex to put it into one number. Consider the
case for multiple signatures - who is going to decide whether the
signature is valid. This has all been discussed about 15 years ago
with the result of writing the gpgv binary which is suitable for most
automated signature verification use cases.

http://lists.gnupg.org/pipermail/gnupg-users/2015-January/052232.html

@martinholovsky
Copy link
Owner

thats ironic, isnt it? gpgv is not in default portage tree
I might add securix signature to verified files and discard gpg completely

@adrelanos
Copy link
Collaborator Author

discard gpg completely

I'd find that very wrong. Killing the patient doesn't count for healing the sickness. ;)

Created a gpg-bash-lib in meanwhile:
https://github.com/Whonix/gpg-bash-lib

Still lacks documentation, but I think it's a sound solution. No negative feedback yet, but also no other users.

Usage examples:

Shall I send a pull request that adapts it?

@martinholovsky
Copy link
Owner

Hi, I saw it already, but its too much code.
btw did you consider different timezone, when you're checking date and time of signature? I have seen there unix time, which should be OK, but I'm not yet oriented in your code.

regarding pull request: if it could be compressed into 10 lines, then sure :]

@adrelanos
Copy link
Collaborator Author

Late answer but better than never.

btw did you consider different timezone, when you're checking date and time of signature? I have seen there unix time, which should be OK, but I'm not yet oriented in your code.

Yes. It's all unix time. Nothing depends on timezone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants