The private key contains the public key. Thus there is no need to export the public key if you already got the secret key.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 10 2021
Pushed the change.
Considering the history of the translation, I concluded that it should be:
把密钥导出到一个公钥服务器上
(the typo was G-A where B-A was expected.)
@guzhongren
This is not GitHub, so, if you want, you need to learn how to submit your change in the form of patch, by using git.
Jun 9 2021
No, sorry. For help please use one of the mailing lists.
Clone and checkout the branch as usual with Git. There is no web editor etc like you might know from github. For your request we need to wait for someone to check your request.
Hey, I found the typo which I reported hasn't been fixed https://dev.gnupg.org/source/gnupg/browse/master/po/zh_CN.po$1962
2.2.23 is an old version. We will soon release 2.2.28 which comes with an updated Simplified Chinese Translation, see rGb0a7132856
There seem to be two parts to this problem. One is the encryption side where gpgtar reports "file has grown" on large files and then the crash when Kleopatra decrypts.
Now also fixed for 2.2.28
Better don't backport this.
Fixed.
I'm not sure if it's worth backporting this to 2.2.
I encountered this bug last year, but I realized that it's hard to make a reproducible case.
For the Data Object of serial number, what I read is this code: https://github.com/Yubico/yubikey-manager
Jun 8 2021
FWIW: Actually the old code assumed that the s/n is at least 4 bytes. IIRC, I once checked the source of the Yubico tools to get this info.
Applied and pushed.
The device with serial number 10000003, it is represented as three bytes: 00989683
Jun 7 2021
These are the versions:
Which version of Kleopatra are you using? And which operating system, e.g. Windows 10?
@dkg
If we support native X25519 format, multiple representations will be possible (there are 32 ways, at least) for a single secret key, because it's the feature of X25519.
In 2.3, the logic to identify Yubikey has been changed (to support PIV application).
In your log, it says:
usb_claim_interface failed: -3
Sorry, I was wrong.
@werner
My patch is for the case if it's better to accept such a key of OpenPGP.
I don't know if it's better or not (yet). The purpose of this patch is to show the point where OpenPGP secret part translates into libgcrypt secret key, concretely.