gpg: Delete secret key after "keytocard".
scd,openpgp: Switch key attributes between RSA and ECC in writekey.
gpg: Delete secret key after "keytocard".
Hint: When the user disabled GpgOL -> Automation -> Automatically secure messages in the configuration of GpgOL he could see the email body again.
Let the compiler control the lifetime of the dialog
Yes, the installation was with the unmodified Installer GnuPG-VS-Desktop-3.1.26.0-Standard.msi
This isn't a support forum. You'd better ask on the gnupg-users mailing list before assuming that you found a bug.
l10n daemon script <scripty@kde.org> committed
rLIBKLEO1aee4ca4245e: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rLIBKLEOdd0fb16c60b1: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
Are you using an actual GnuPG VSD installer? I'm asking because, as far as I know, several actions are disabled via immutable config entries that are only shipped to customers.
Closing this one - see T6378
werner moved
T6378: keytocard: invalid value from
Restricted Project Column to
Restricted Project Column on the
Restricted Project board.
werner changed the status of
T6378: keytocard: invalid value from
Open to
Testing.
Fixed in 2.2 need to check 2.4
scd,openpgp: Switch key attributes between RSA and ECC in writekey.
Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.
There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check
gpg: Allow no version information of Yubikey
I agree. Something called shouldn't change existing data. (Updating existing data to a new format that doesn't alter the semantics of the existing data is okay.)
Use correct INSTALL_TARGETS_DEFAULT_ARGS
Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.
agent: Do not overwrite a key file by a shadow key file.
agent: Make --disable-extended-key-format a dummy option.
I did some reworking and the outcome of the READKEY command is now (agent log):
I checked it: There was an empty , and there still is.
Trying it again today, I still get error messages most notably about failed self-tests, but surprisingly the window is no longer empty.
Instead it seems to take an eternity (minutes, actually still not finished after three minutes) until the certificate cache is loaded.
Maybe the problem is the "Check Point Endpoint Security" being active on the client. It looks as if it prevents use of Kleopatra.
As I don't have administrator rights ("for security reasons"), I cannot analyze what's actually going on.
l10n daemon script <scripty@kde.org> committed
rLIBKLEOd1ab3070ae7b: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRAcd1356c1a2b7: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
tests: Improve test coverage for FIPS service indicators.
fips: Explicitly disable overriding random in FIPS mode.
fips: Explicitly allow only some PK flags.
doc: Document the new FIPS indicators.
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA4e9a7de6f364: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.
For non-vsde-enabled installations the green check symbol is okay because in the given context (encryption) it indicates that the key can be used.
GIT_SILENT: don't duplicate KF_MIN_VERSION
GIT_SILENT: time to increase version
Seeing that there are "groups" in Kleopatra, I read the docs, and they suggested that the groups are for addressing multiple recipients.
GIT_SILENT: time to increase version
Settings -> Configure Groups.
It seems that you are missing the step "Create a new file called gpgconf.ctl in the folder Gpg4win_Portable/bin."
I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.
agent: Make --disable-extended-key-format a dummy option.
ikloecker moved
T6373: Kleopatra: Show progress dialog when moving decrypted archive to final destination from
Restricted Project Column to
Restricted Project Column on the
Restricted Project board.
gpgconf,w32: Also print a GnuPG Install Directory Registry entry
Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.
l10n daemon script <scripty@kde.org> committed
rLIBKLEO148c82f9dddc: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA743e9c995b9a: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rLIBKLEOb65a99aab857: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA83b8d2b49a17: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
Pushed to this site. Thanks for noting.
l10n daemon script <scripty@kde.org> committed
rLIBKLEO15b6685e38f3: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rLIBKLEOa731d8d9084b: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA1f8b8867ab1d: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
GIT_SILENT: master is open
GIT_SILENT: master is open
GIT_SILENT: prepare 23.04 beta
GIT_SILENT: prepare 23.04 beta
l10n daemon script <scripty@kde.org> committed
rLIBKLEO72f744fbc57d: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRAb62e0b97d6a3: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRAfa6c4acf42b7: SVN_SILENT made messages (.desktop file) - always resolve ours (authored by l10n daemon script <scripty@kde.org>).
SVN_SILENT made messages (.desktop file) - always resolve ours
l10n daemon script <scripty@kde.org> committed
rLIBKLEO51a36790ac6b: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA505f6dbca9db: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
I think this is still missing a tag in git (I don't see it in )
GIT_SILENT: master is opened
GIT_SILENT: prepare 5.23.0 beta
l10n daemon script <scripty@kde.org> committed
rLIBKLEO8a35b23b60f1: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA0b9800a69ca9: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA2debdc4244d0: SVN_SILENT made messages (.desktop file) - always resolve ours (authored by l10n daemon script <scripty@kde.org>).
SVN_SILENT made messages (.desktop file) - always resolve ours
l10n daemon script <scripty@kde.org> committed
rLIBKLEO8ebdb98887b9: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
l10n daemon script <scripty@kde.org> committed
rKLEOPATRA3fb2b73c0ee5: GIT_SILENT Sync po/docbooks with svn (authored by l10n daemon script <scripty@kde.org>).
GIT_SILENT Sync po/docbooks with svn
Albert Astals Cid <aacid@kde.org> committed
rKLEOPATRAb1ec928003af: GIT_SILENT Upgrade release service version to 23.07.70. (authored by Albert Astals Cid <aacid@kde.org>).
GIT_SILENT Upgrade release service version to 23.07.70.
Albert Astals Cid <aacid@kde.org> committed
rKLEOPATRAb9dd9af8e0eb: GIT_SILENT Upgrade release service version to 23.03.80. (authored by Albert Astals Cid <aacid@kde.org>).
GIT_SILENT Upgrade release service version to 23.03.80.
I've run into a variant of this, too. If I generate they key just using . One needs to use
@gniibe I have submitted D565 to change the error message on curses initialization to "Required environment variable not set"
Show indicator for compliance of selected keys
Show status of compliance in tooltip
Use neutral icon for non-compliant, valid keys
Set status string also for trusted keys
dirmngr: Add command "GETINFO stats".
Its not used, so it can't harm.
Also recall that Antivirus software needs to search for a competitive advantage over other vendors and in particular over Windows Defender. Thus they need to show some extra positives compared to the Windows Defender. Who care whether this is a false positive - ppl like to get some evidence that their new AV software has a (phoney) advantage.
It effects Yubikeys an ZeitControl cards (version 3.4)