You are welcome. If my bad English makes it difficult, here is another document.
http://web.monkeysphere.info/doc/trust-models/
You can find the explanation:
So "full" ownertrust on a key is only meaningful as long as there is a trust
path to some User ID on that key already. "ultimate" ownertrust is meaningful
anyway, because presumably you control that key.
Ok I think I get it. I appreciate you taking the time to explain it.
Thanks.
Ok I think I get it now. Thank you for explaining it to me. I appreciate it
Adding "ultimate" trust means: you are specifying it's your own key. GnuPG
doesn't check if your own key is signed by another your own key (or you really
have corresponding private key).
Let me explain the validity of public keys.
put them to a set of valid keys.
globally), it's all valid. Put them to a set of valid keys.
Next, it checks "full" or "marginal" trust to a public key.
signed by this key as it's reachable by "full" trust.
reachable by "marginal" trust adding a point.
the set of valid keys. If it can be reachable by "marginal" trust by 3
(default) different keys, it will be also in the set of valid keys.
recursively, to the newly added valid keys. Don't repeat too far. Stop if it
goes 5 (default) times.
In other words, adding trust (by --edit-key) to a valid key makes it possible
for another key to be validated by that key. Adding trust (by --edit-key) to an
invalid key doesn't make that invalid key valid. (If it's "full" or "marginal".)
But why does marking it as ultimately trusted ignore that it was never signed?
scdaemon is part of GnuPG.
OpenSC is entirely unrelated to GnuPG.
Please take this to a mailing list (e.g. gnupg-users)
Ah sorry I understood you were saying the bug is in OpenSC. Where can I report
to scdaemon? I can't find it.
FireFox is not GnuPG and does not support the OpenPGP card.
As I said, the card may work with gpgsm because I once developed support for the
Belgian eID card. But it is likely to need some tweaking (gnupg/scd/app-p15.c)
I saw that it says not supported, but DNIe is actually supported. I can use it
flawlessly with Firefox for instance.
Please see:
https://github.com/OpenSC/OpenSC/wiki/DNIe-%28OpenDNIe%29#update-2013-08-27
https://github.com/OpenSC/OpenSC/issues/774#issuecomment-222468916
Thanks!
Given that a released version of libgpg-error does now exist, the problem should
be solved even for further versions taken from the repo.
A beta version is not a released version. For example SO numbers may be
different. BTW 1.22 has been released.
There's an issue somewhere: I built & installed libgpg-error 1.22 beta exactly
the same way as I did with 1.21. I'm not surprised by your answer: you guys have
already dismissed another perfectly valid issue report.
Something went wrong wile you installed libgpg-error. The linker picks up
another version of the library. If you need help, please ask on gnupg-devel.
Glad, that it now works for you.
libgcrypt 1.7.0 is out. Please test with it.
If I understand correctly, we cannot compile latest libgcrypt because:
That's unusual.
So I rebuilt libgcrypt with libgpg-error stable 1.21 installed in /usr, and it
passed.
It is true that I have built & installed libgpg-error from git master into
/usr:
./configure --enable-shared=yes \
--enable-maintainer-mode \ --prefix=/usr --sysconfdir=/etc --localstatedir=/var
But what do you mean by "properly install the library"?
Thank you! All set.
I would not consider this a bug. sshcontrol is used to enable certain keys for
use with ssh. Updating keys is useless if they are already available.
If you remove the keys from sshcontrol you disable them. I would suggest to put
a '!' in front of the keygrip instead of deleting the line in sshcontrol. This
allows to re-enable a key w/o problems.
Thanks for testing 2.1 and for reporting the results.
Good to know that it works now.
There are still problems with libtool; see recent Debian problems on building
gnupg for Windows. Thus we won't chnage libtool for 1.7.0.
That works.
Thanks for your kind support.
OK, thanks for the response Werner. Perhaps this bug then is to update the website
docs to reflect what I gather may be big changes to this feature as compared to earlier
gnupg releases.
It seems that everything that can be found here (the best source I have found for using
gnupg w/ DNS) is now outdated and will no longer work:
http://gushi.org/make-dns-cert/HOWTO.html
I wanted to learn more about the new changes but I was only able to find the following
references which I'll document here in case someone else comes across it.
Unfortunately, I won't be able to test out the new method as I don't run my own bind
server and like many of us rely on a DNS provider that doesn't allow me to create the
form of DNS record output by --print-pka-records.
I only found three references to the new '--print-pka-records':
2.1.3 Announce:
https://lists.gnupg.org/pipermail/gnupg-announce/2015q2/000365.html
"* gpg: New option --print-pka-records. Changed the PKA method to use
CERT records and hashed names."
gnupg docs:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html
"--print-pka-records
Modify the output of the list commands to print PKA records suitable to put into DNS
zone files. An ORIGIN line is printed before each record to allow diverting the records
to the corresponding zone file."
And finally an announcement from you in gnupg-devel from last year where you state that
all of the old functionality for PKA has been removed and replaced with something
entirely new (which is just for key 'validation' and not for key installation?):
http://marc.info/?l=gnupg-devel&m=142488047809150&w=2
Sorry that there has been no response on this but we did not have time to work
on gpgOL.
GpgOL for Outlook 2003 is no longer maintained and support for this in gpg4win
is likely to be dropped soonish.
I'm closing this as nobug to help us clean up the bugtracker. The word editor is
not supported in Outlook 2003 and we will not add support for this. Sorry.
Uhm five years and not reply ;-) Sorry but we did not have much time to work on
GpgOL and the little time we had we spent on Outlook 2010 and later (which is a
different codebase)
The code for 2003 and 2007 is still basically unmaintained. We are looking into
the possibility to remove 2003 support and use the 2010 and later codebase for
2007, too. From your debug output it looks like you are using exchange. This is
not supported for the < 2010 addon. (It is supporeted in the current development
version that will be part of gpg4win 3.0.0)
So you can either switch to Outlook 2010 or later (and for now use the gpg4win
3.0.0 test version) ( https://wiki.gnupg.org/Gpg4win/Testversions ) or hope that
we will enable that codebase for 2007, too.
Sorry that I am marking this as nobug but we will not fix this for 2007 only and
in later versions it already works.
Oh, I was not aware of that bug and disabled S/MIME by default in the current
development version.
I'll make the default depending on the Outlook version.
If you check the do-while above you will notice that after the loop LINE is
guaranteed to always end with a LF. Thus strpbrk will always succeed.
I'm marking this issue as resolved.
Pretty old. We should re-evaluate this for the 1.7 release.
For the record Rolf Eike Beer still maintains KGpg (I was not aware of this when
i wrote T2048 (aheinecke on Aug 28 2015, 10:54 PM / Roundup))
And he is planning to port it to Qt5.
See: https://mail.kde.org/pipermail/kde-community/2015q3/001651.html
Please leave this issue closed here. This bug either belongs in the Fedora
Bugtracker or in KDE's bugtracker.
On 6 November, there was finally some movement on the 22 July Bug I filed at:
https://bugzilla.redhat.com/show_bug.cgi?id=1245732
Rex Dieter provided the underlying explanation of the KGpg autostart failure on
Fedora 22 (or newer) systems:
He stated:
"Simple reason is that plasma5 doesn't support kde4 apps' use of
X-KDE-Autostart-condition"
Note: Rex is also developing/testing a patch to address this plasma5
shortcoming for Fed 22 systems.
Importantly, and as I had suspected and alluded to, this plasma5 lack of support
explains why the KGpp failure to autostart occured *only* on my Fed 22 systems,
and did not impact any of the other KDE operating systems I use.
I have upgraded all my Fed 22 systems to Fed 23, where the KGpg autostart
currently continues to persist. I have documented the workaround in the Bug
report linked above for anyone impacted. This workaround also works in Fed 23.
Hopefully, this issue will be fully resolved in the next Fedora-approved release
of KGpg.
Fixed in 6897bbf.
$ gpg2 --multifile --sign --encrypt-files /tmp/foo /tmp/bar
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: --sign --encrypt does not yet work with --multifile
This support request appears to be resolved. Closing.
Sure. The issue of consistency across translations is just nitpicking.
The issue of parsing is solved as +notabug for gnupg, since the bug was actually in
ZSh - and is now fixed. Even in older Zsh version can be avoided by decoupling stdin
and stderr in the parsing, basically using --status-fd. I should have done that in the
first place. Apologies for emphasizing this here, as Gnupg offers all the correct
facilities to decouple the output streams.
Unrelated with the issue above, I still think that normalization of white-space usage
across different translations would be an improvement, but since doing it requires a
semantic analysis that is contextual to the language, its quite hard to realize now.
Perhaps a good idea that documentation for translators include a note about white-
space usage. But again, this is nitpicking. Feel free to close the issue.
I fully agree and I can only repea: Do not parse the output intended for humans
but use the --status-fd option. There is no excuse in not doing so.