Yes we could add that. Okular has this actually. For now we were Happy to go with the system default in the last version :)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 21 2024
Feb 20 2024
This seems to depend on the Platform theme. Under Windows I get the same results as you on linux It works fine with me
since we are currently in the process of upgrading our UI Framework we will need to recheck this. To avoid too many duplicates in the tracker I will merge this ticket into our general "revisit dark mode" task T6076: Kleopatra: Many icons are hard to see if the dark high-contrast mode is activatedFeb 19 2024
Since there are some files that would simply have to be created each time under $GNUPGHOME, I've been thinking a bit more about what sort of approach to take for "fallbacks."
Feb 16 2024
Feb 15 2024
That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal
Funnily enough, runtime sockets already adhere to the XDGBDS somewhat by using $XDG_RUNTIME_DIR/gnupg as their path, while everything else uses strictly $GNUPGHOME or ~/.gnupg with no other alternative. Of course, I completely understand that the priority for this is rather low, but I am still happy to look into providing a patch myself that would add these fallbacks if it would help expedite the whole process.
Portable Apps are a Bad Idea because they bypass important security mechanisms. In any case please tak such discussions to a mailing list and please do not use the bug tracker for this. The audience of bug reports is pretty limited.
Talked to werner about this. We will but the list of signed files into the Gpg4win repo proper to that signing is part of the normal Gpg4win release (of course only if you have a signing key configured)'
Werner wants the import via gpg-agent
In master, I applied changes for include files which don't harm current target of MinGW-64.
It's true that under $GNUPGHOME (~/.gnupg/), there are multiple things: configuration files, user-specific data files (private keys, public keys, the trust database, and revocation certificates), user-specific state files (like the lock files and random seed), possibly runtime sockets, and executable/script for card reader. Some careful handling might be needed for making backup and doing version control for that.
Feb 14 2024
Yeah I also signed all the binaries for the last Gpg4win release (4.2.0). I think we should support the case that only signed binaries are allowed on a system.
I guess that's what it is called. A person in the forum told that GpgOL could not be loaded in Outlook and saw that the signature is missing in the new version. But it was there in version 4.2.0. With the command Get-AuthenticodeSignature I could confirm that this is the case.
You mean the Authenticode signature? Afaics, only the gnupg files come with such signatures.
Feb 13 2024
So I cherry-picked this onto 2.4.4 and I ended up with a failing build due to failed tests (it built fine without the patch)
Feb 11 2024
This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?
Feb 10 2024
We check the actual used signature and the corresponding (sub)key. Whether you trust this key is a different thing and we are not able to check that. Note that the same subkey may be used with different primary keys. The whole point of gpgv is to that you pass a list of trusted keys - actually this makes this new option superfluous but in gpg it makes sense. It was easy to add it to gpgv, though.
Feb 9 2024
Feb 8 2024
Checking if the file already exists doesn't help. In fact, typically the file (containing the shadow key for the card key) will already exist. But one could check if there is already a private key with this keygrip. Then restoring could be refused, so that the worst that can happen is that the shadow key (which can be recovered from the smart card) is overwritten with a corrupt file.
I think the attack ingo talks about would mostly be covered by checking if the file already exists before moving it into the private directory.
Feb 7 2024
Feb 6 2024
Feb 5 2024
Do note there could be subkeys as well.
Jan 26 2024
Fixed in 0.3.2.
Jan 25 2024
Jan 24 2024
Just a reminder, this is important for 384 bit keys (see T6379).
These gpgsk files are standard private-keys-v1 files with an additional Backup-info line showing for example the keygrip.
There are no certificates in the file, thus we can either use gpg or gpgsm as driver.
Hard to test without instrumenting the code.
Tested during development.
@alexk and me tested this. The core functionality works.
Works for the two sample RSA cards. Ticket may eventually be re-opened if we run into problems with ECC cards.
Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24
Jan 23 2024
It is already implemented and will soon show up in 2.4.4 -)
Jan 22 2024
Jan 20 2024
Sorry, we won't do that. Please search on the Net for reasons why this is not a good idea. In any case you better move to Ed25519 or - if you really feel like this - to X448. The GnuPG FAQ als gives a rationale why larger keys are not useful.
Jan 19 2024
- To configure a keyserver none I have now T6950: Kleopatra: Usability improvements for directory services configuration
- For tarball naming I created T6952: Gpg4win build system: Include commit hash in tarballs from gen-tarball.sh
- For the about dialog I have T6953: Kleopatra: show commit id in about dialog
In T6946#181608, @werner wrote:The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.
A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.
But thanks for reporting! I really like feature requests so please do not feel discouraged to request more features.
Sorry, but this is a "Wontfix" we do not support this by choice. We think that adding photos to certificates both gives a wrong sense like "I know that picture, iit must be this person" and also increases the sizes of the certificates a lot. It is in our opinion a misfeature in the OpnePGP specificationl.
I noticed the Debian bug and was about to answer but a feature request is also a good thing.
In T6708#181592, @werner wrote:I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.
I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.
Sorry, it was my fault building the test installer.
To be clear: This ticket is only about GnuPG (more precisely dirmngr) and the changes are included in VSD and Gpg4win.
Jan 18 2024
Hi, ebo I would still think this is resolved. Because it was never meant that the user manually enters the value of "none" because there is no hint for the user that "none" is a reserved word. It should either be administratively configured which does not make much sense for Gpg4win or provided by the distribution. If left empty the default of GnuPG should be used. If we really want users to deactivate keyserver access by using "none" in the dirmngr.conf a much better solution would be a checkbox for this. In that case I would open a new issue.
The fix was not included in the Testbuid...
Does not work in Gpg4win-4.2.1-beta178
Jan 17 2024
Example output:
Jan 16 2024
Interesting. I need to look closer at it. I scheduled it for 2.4 but it won't be in the forthcoming 2.4.4. There are still other interesting things on the short list (e.g. timestamping support) but we may do that only in 2.6.
Thanks for the report. It comes right in time for the next release. It might already be fixed due to a lot of changes in the pkcs#12 parser.
Jan 15 2024
I think this is resolved now.