After trying some more, I found out some things.
I just have to run "gpg revoke.asc", without any options.
But then, the reason text that I entered when generating the revocation
certificate is not shown. Nor is the numeric reason.
gpg: standalone signature of class 0x20
gpg: Signature made 02/22/15 15:46:23 Eur using DSA key ID BACCF5EE
gpg: standalone revocation - use "gpg --import" to apply
And I dont understand what “class 0x20” means.
How much time would it take to migrate to QT5?
We already have that "confirm" flag for ssh and thus adding code to use it for
the extra-socket feature should be easy. The open question is how to disable
this feature on a per key base. A ~/.gnupg/confirmcontrol or similar file could
be used to record those keys which do not need confirmation or if persistance is
not required a checkbox in pinentry could be used to show the confirmation
dialog only once per session.
This will eventually be done but not right now. I keep this bug report as a
reminder.
I granted you permissions to edit other bug reports. However, this patch is not
required.
I just changed the remaining http references to gnupg.org to https (on master).
Thanks.
Changing them in coments and in the outdated FAQ does not make sense.
Nope. See my comments at
https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052401.html
Should be fixed by commit 017c6f8fba9ae141a46084d6961ba60c4230f97a
on 2014-06-24.
Okay, that took long :-(: commit da4db172 - will go into 2.1.2.
I added options shown with --help but missing in the man page.
However, --help won't show everything listed in the man age and
frankly there are even more options not listed anywhere (to see them
use --dump-options).I also kept one British translation ;-)
Thanks for the report.
That's fine... or just make the wording in the man page more clear. Under
--verify, it talks about using --output with cleartext signed data. That seemed
to imply (to me) that --output is used _with_ --verify. I think it should be
clearer that --output is to be used _without_ --verify or that --output has no
effect when using --verify.
So this could be treated as just a documentation bug rather than create yet
another new option.
For what it's worth, I don't think backward compatibility is an important
concern here. If someone was using --output with --verify before, they likely
were under the impression that the combination worked when in reality the two
options together just weren't a valid combination. It seems unlikely that
anyone would depend on --output being ignored when used with --verify, and so
making the combination work now should not cause legitimate compatibility problems.
If the combination of --output with --verify is not made to work, there should
probably be a warning emitted (in addition to fixing the documentation).
In summary, it seems to me that viable options are at least the following:
the rare use case of someone depending on current behavior of the currently
invalid combination)
discussing using --output
--current in the current implementation <= 2.1.1)
These are not necessarily exclusive choices.
I guess I would prefer to allow the combination to work or warn and fix the
docs. Not as keen to add yet another new option - there's already a lot.
I can work up a patch if we can settle on a direction.
MD5 is not used bu OpenPGP. It is allowed for backward compatibility but even
that has been dropped for GnuPG 2.1.
The use of SHA-1 fingerprints is hardwired into OpenPGP and to change this a
complete new key format needs to be specified. In any case the fingerprints
are not a problem right now.
Using Base64 fingerprints are actually a bad idea because they are to hard to
compare for a human.
P.S.
SHA512 probably would be the right thing. If someone's too lazy to compare such
a long fingerprint, he can still choose just to compare just one half of it.
Sure, a standard for that would be great.
MD5 is pretty much broken for security purposes and I would wonder, if that's
not also true in the context of OpenPGP.
You're probably much closer to the people responsible for the OpenPGP standard.
Are there any efforts to introduce SHA512-BASE64 fingerprints? (or at least SHA256)
Such fingerprints are not specifed by OpenPGP. It is also questionable whether
this will be used, given that one could also print an 256 bit ECC key directly.
Yeah, that is a bit different than the fingerprint but it raises the importance
of have a standard before coming up with an arbitrary fingerprint scheme.
Linux specific things are a no-go unless really needed.
Yes, things could be adjusted to wake up only if reallyneeded but it requires
more code.
What is the problem you try to solve? Do you have any measurements that show
that battery life is improved by changing this?
Well if my reading is correct, the housekeeping happens in handle_tick(). 3
things are happening:
linux)
don't need to wake up every two seconds to check it.
frequently?
dirmngr also seems to wake up often to check the if it's time to do housekeeping
(which it does every 10 minutes). Seems like this could also be improved?
scdaemon does seem harder, but not everyone is using smartcards.
This won't be fixed for 2.0 but I will consider to do something about it in one
of the next 2.1 releases.
No, you do not need a second bug for --delete-secret-key.
original; report was for the dirmngr package. Won't fix it there.
The context menu of the key manager now has a "refresh key" item.
OpenPGP does not specify this. It is actually not easy to add another format
becuase that opens the path for all kind of attacks. Like with ELF comment
section you can do the same for any other data format. No, there is no ELF
parser in gpg and there won't be one for any other language.
Please take this to the gnupg-users ML or to the OpenPGP WG. Thanks.
Additionally to T1665 (wk on Jul 03 2014, 11:13 AM / Roundup) (outlining that a trust path to the global SSL companies
is available and thus resolving this):
https://files.gpg4win.org is verified by a certificate that is available over
https://ssl.intevation.de/ this site is "verified" by one of the preinstalled
companies. (You are hopefully aware that you just have to send them some bucks
and some unsigned mails with an @intevation.de address claiming that you are
intevation.de to get such a certificate)
We also bought a certificate for codesigning so that in Windows itself you get
an assurance that one of the >100 Root CA's in their certificate program earned
some money from us ;-)
Please check the openpgp signatures or the checksums in our release
announcements and decide for yourself if you trust us. We can just buy your
trust otherwise.
The language designers will almost certainly return the ball by saying that it
is not their job to define signatures :-)
Elves and dwarves aside, could we have a bottom signature format that would keep
files readable for Shellscript, Perl, Python, plain text and maybe a few more by
using the last line in the file as in my example? This is the main request here.
That is something you need to build into your language's interpreter or into the
OS proper (for the ELF, COFF, or the shebank hack). We can't do anything in gpg
with that. It is of course possible todo that. For example many years ago, I
wrote such a system for ELF with gpg used by a tool for signing and a dedicated
verification module for the OS.
If you like to discuss this, you may want to post to the gnupg-users ML.
Or use the new --quick-sign-key command ...
This was fixed in gpg4win 2.2.2
With pinentry 0.9 this works in pinentry-gtk under GNU/Linux.
With pinentry 0.8.4 This works in pinentry-qt4 under Windows.
Gpg4win includes a version with paste support since 2.1.0 (I think)
ssh-add only looks for private key information. If there is a id_rsa-cert.pub file it
will add the certificate, but one cannot add a certificate alone.
There are a couple of problems:
it is added via agent forwarding it fails.
use. Some cards allow certificates to be stored on the card, and it looks from the
source to scdaemon that there is a way to read it and return it to the agent.
I could give this a try: in the case of #2, do you think it would be a reasonable
addition to gpg-agent's protocol to look for ~/.ssh/id_{rsa,dsa,ecdsa}-cert.pub when
handling a card-based private key? The cert is public info so only better portability
is gained by storing it on the card.
Feel free to send a patch ;-). You may want to publish this feature request on
some mailing list and ask for help.
Isn't it possisble to convert it to standard ssh format and use that with ssh-add?
I am currently lacking the time to add this to gpg-agent.
That is really not a bug but a design decision.
The keyserver interface in dirmngr is quite modular and the idea is to add new
interfaces as need arises. Simlar to the smartcard support in scdaemon.
Given that there is no more need for copyright assignments, adding patches shold
not be major problem. So, yes pacthes are accepted - please do it for now as a
complete separate ks-engine-hkpms.c. If we later see that it shares much code
with *-hpk we can merge it then. This better isolates bugs.
Please stop spamming thius bug tracker.
Interesting.
Use "=c" does now work with commit bc8583f2.
Well, I removed all support for GPG_AGENT_INFO.
What "that" are you referring to? In all the versions of GPG I've tried, 1.4,
2.0, 2.1 including this current one in git, it is possible to create a
Certify-only master key by toggling off "Sign" (and "Encrypt", for RSA).
I am saying this should be possible for the "=flags" syntax as well. I would be
happy with either "=" or "=c". The latter is clearer, but inconsistent with the
existing syntax in git which ignores "c" completely, and just forces Certify on
for the master key and off for the subkey.
$ gpg2 --full-gen-key --expert
[..]
Please select what kind of key you want:
[..]
Your selection? 8
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt
[..]
Your selection? s
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify Encrypt
[..]
Your selection? e
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify
[..]
Your selection? q
[..]
GnuPG needs to construct a user ID to identify your key.
Real name: Testing
Email address: lol@test
Comment:
[..]
gpg: key 0822FCC2D521C45C marked as ultimately trusted
public and secret key created and signed.
[..]
$ gpg2 --edit-key lol@test
[..]
Secret key is available.
pub rsa1024/0822FCC2D521C45C
created: 2014-10-02 expires: never usage: C trust: ultimate validity: ultimate
[ultimate] (1). Testing <lol@test>
gpg>
That was never possible.
Hi, this does not currently allow me to set the master key to Certify only. If I
enter "=" or "=c" it just ignores me and goes back to the default value. Looking
at commit 7ff4ea21 I'm not sure why this is the case, since current should be 0
at the end. Setting "=a" gives me a CA-use master key as expected.
It would be good to note in the help text that a master key always has the C
flag, and a subkey does not (as far as the "=" syntax is currently implemented).
Thank you! This solution sounds good, I will test it this weekend.
Done for 2.1 and 2.0.
Use "=esa" to set all capabilities. Enter '?' for help ;-).
GOT_IT merely tells that a line was received. There is and can't be any more
semantics.