Yes, I am ready to accept write access to the Scute repository.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jun 23 2017
Jun 23 2017
gouttegd added a comment to T3195: Scute does not reliably find the agent socket, especially if it is relocated to /run.....
FWIW, I ran a make check today and got several failed tests when using the extended key format. Checking out master to see whether this was caused by another patch I am working on, showed that it worked on master. Checking out my local branch again, then passed the test.
• werner assigned T3195: Scute does not reliably find the agent socket, especially if it is relocated to /run.... to justus.
Justus, please apply the patches.
I have tested this and it appears to fix the leak of gpg-agent processes in virt-builder, thanks.
I commited a change which should fix this on Linux
Well, this is a regression due to us creating creating /run/user/gnupg/ socket directories now on the fly. Thus there is no more need to create non-default home directories via gpgconf. Now, gpg-agent watches the socket file and terminates itself as soon as the socket file vanishes. Before that change the socket for a non-default home directory was created in the homedir itself and thus removing the homedir also removed the socket file and in turn gpg-agent terminated itself.
This is such a large change that I feel uneasy to close the bug before we know that there are no regressions. This Means we need to wait whether the next release will break.
Jun 22 2017
Jun 22 2017
gouttegd added a comment to T3195: Scute does not reliably find the agent socket, especially if it is relocated to /run.....
I think the best method to make sure Scute can always find the socket is to use gpg-connect-agent to ask for the socket: we call gpg-connect-agent 'GETINFO socket_name' /bye and read the reply.
Jun 21 2017
Jun 21 2017
Jun 20 2017
Jun 20 2017
Fixed in 48aae8167dcae80d43b08167a88d9eb170781a04.
justus closed T3212: when canceling pinentry dialog while creating a new subkey, secondary pinentry dialog shows up as Resolved.
Fixed in badc1cdae52bd434e5fac2e4275575afeccc2837.
justus triaged T3212: when canceling pinentry dialog while creating a new subkey, secondary pinentry dialog shows up as Normal priority.
Agreed, that is odd.
Jun 19 2017
Jun 19 2017
I'm not sure I understand the problem. Importing that key seems to work just fine. Listing as well.
Jun 17 2017
Jun 17 2017
here's a public key version of the same key. it was available easier and should reproduce the bug just as well
Jun 14 2017
Jun 14 2017
justus closed T2236: Importing a key with badly ordered packets doesn't reorder it, and while --edit-key does reorder it doesn't move the signature packets to the right place as Resolved.
Fixed as of 9b12b45aa5e67d4d422bf75a3879df1d52dbe67f.
justus added a comment to T2236: Importing a key with badly ordered packets doesn't reorder it, and while --edit-key does reorder it doesn't move the signature packets to the right place.
It doesn't seem to impact performance significantly:
Jun 13 2017
Jun 13 2017
In T3203#98567, @Valodim wrote:The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)
user ids with length 0 do conform with rfc4880, though
I'd suggest to skip such user id. Actually I had in mind that we did that in the past - but I may be wrong.
• werner added a comment to T2236: Importing a key with badly ordered packets doesn't reorder it, and while --edit-key does reorder it doesn't move the signature packets to the right place.
Justus: When you have implemented that, can you please do a test with my key before and after? As you may know, I have hundreds of vanity signatures so that I need to have
The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)
Out of curiosity, how did you create the key? What is the use case?
This is fixed now. The fix 15d2a009931f44a60b9df6325f837add208459d6 should be easy to backport.
Still, looks totally fine to me:
Jun 12 2017
Jun 12 2017
In T3187#98531, @werner wrote:I will try to reproduce it. It might be that --passwd also trigerred the conversion to the new format.
I will try to reproduce it. It might be that --passwd also trigerred the conversion to the new format.
Odd, I cannot reproduce this:
Jun 8 2017
Jun 8 2017
justus moved T3088: document --no-use-tor and its interaction with --use-tor from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T3117: improve warnings when daemons are older than gpg from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T3200: Fix sym cipher discrepancies in gpg4vsnfd evaluation documents. from Backlog to Blocker on the gnupg (gpg22) board.
justus renamed T3194: Export of keys fails (gets mangled) if stdout is redirected to a file on Windows from GPG on Windows 10: Order of export-key command affecting exported key quality? to Export of keys fails (gets mangled) if stdout is redirected to a file on Windows.
justus triaged T3054: dirmngr only using cAcertificate attr type when querying LDAP directory as Wishlist priority.
justus triaged T3087: dirmngr, when configured to use an .onion address, should not permit HTTP redirects to a non-onion address as Wishlist priority.
justus triaged T3088: document --no-use-tor and its interaction with --use-tor as Wishlist priority.
• werner added a comment to T3191: Make sure only listed algorithms are used with --compliance=de-vs.
Regarding CFB: This needs to be decided by the evaluators. They know about the CFB problematic in their own documents. Thanks for pointing out discrepancies in the specs. I'll open a new task for it.
Implemented. The policy should be easy to adjust later on.
4.4.1 does not allow the use of AES-128 CFB as a cipher to encrypt the body of messages, but 4.4.2 even lists AES-128 CFB as conforming to VS-NfD. Furthermore, 4.1.1 allows,the use of AES-128 CFB as a cipher to encrypt the body of messages. I'm going to assume that this is a bug in the specification and also allow it for symmetric encryption.
Jun 7 2017
Jun 7 2017
4.2.2 lists session keys for ciphers that are not allowed.
thanks for help - could have been my mistake as well, so better look twice.
"werner (Werner Koch)" <noreply@dev.gnupg.org> writes:
Sorry. I looked at path_add and not at path_remove, see my garbled line numbers I started at 1062 and not 1162.
void __declspec(dllexport)
path_remove (HWND hwndParent, int string_size, char *variables,
stack_t **stacktop, extra_parameters_t *extra)
{
char dir[PATH_LENGTH_LIMIT];
char is_user_install[2];
char *path;
char *path_new;
int path_new_size;
char *comp;
const char delims[] = ";";
HKEY key_handle = 0;
int changed = 0;
int count = 0;
HKEY root_key;
const char *env_reg;Hmm, why do you think this is important? The use cases I can see are
I don't see the bug. Please elaborate. path_new is is freed in line 1065 but if this condition does not match it's freed in line 1079.
Jun 6 2017
Jun 6 2017
justus triaged T3194: Export of keys fails (gets mangled) if stdout is redirected to a file on Windows as Normal priority.
Jun 1 2017
Jun 1 2017
justus moved T3187: Checksum error with extended-key-format and --paswd on a subkey from Backlog to Blocker on the gnupg (gpg22) board.
FWIW, I think that document describes some nonsensical policies, but I will implement it to the letter for now, it is easy to change later on.
I found a bug in ST-Gpg4VSNfD-v0.6.pdf, page 21 incorrectly refers to RFC6337 instead of RFC6637.
May 31 2017
May 31 2017
justus triaged T3187: Checksum error with extended-key-format and --paswd on a subkey as Normal priority.
justus edited projects for T3187: Checksum error with extended-key-format and --paswd on a subkey, added: gnupg (gpg22); removed gnupg.
May 29 2017
May 29 2017
justus moved T2990: dirmngr fails with IPv6 nameserver in resolv.conf from Backlog to Blocker on the gnupg (gpg22) board.
justus edited projects for T2990: dirmngr fails with IPv6 nameserver in resolv.conf, added: gnupg (gpg22); removed gnupg.
May 24 2017
May 24 2017
Fixed as of 525f2c482abb6bc2002eb878b03558fb43e6b004.
justus moved T2908: dirmngr can't be build w/o LDAP from Backlog to Wishlist on the gnupg (gpg22) board.
justus claimed T2423: configure: error: Sorry, the current implemenation requires mmap. due to empty CFLAGS (missing -fPIC).
@werner, can you please quickly outline how you imagine this to be fixed? Our jabber discussion is gone from my memory, and my client does not keep logs for MUCs for some reason.
justus moved T2917: --locate-key should re-fetch key via WKD if it is expired from Backlog to Blocker on the gnupg (gpg22) board.
justus moved T1173: gpg has no easy way to view the reason and description of revocation sigs from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T1537: gpgv does not handle expired or revoked keys from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T2106: Support SHA-256 fingerprints for ssh from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T2381: Add more support for profiles in gpgconf from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T2398: finger support using SRV DNS records from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T2935: use-tor should have a third possible value, "if available" from Backlog to Wishlist on the gnupg (gpg22) board.
justus moved T2940: dirmngr fails for hkps when http-proxy is in use from Backlog to Wishlist on the gnupg (gpg22) board.
May 15 2017
May 15 2017
justus added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.
Automatic creation of socket directories creates cleanup trouble for projects previously relying on the agent-shutdown if $GNUPGHOME is removed: https://notmuchmail.org/pipermail/notmuch/2017/024550.html
Apr 28 2017
Apr 28 2017
• werner edited projects for T2935: use-tor should have a third possible value, "if available", added: gnupg (gpg22); removed gnupg.
Apr 26 2017
Apr 26 2017
dkg raised the priority of T2236: Importing a key with badly ordered packets doesn't reorder it, and while --edit-key does reorder it doesn't move the signature packets to the right place from Normal to High.
Can we activate this for --import and --recv-key as guilhem requested?
Apr 4 2017
Apr 4 2017
Mar 30 2017
Mar 30 2017
Mar 24 2017
Mar 24 2017
• werner added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.
We also have a discussion of the mailing list. It does currently not make sense
to continue here.
The problem of NFS mounted home directories is _real_ and we have a solution for
this which is better than the old redirection hack.
The problem with too long socket names is not severe and has been around for
decades (for other software and 14 years for GnuPG). There are workaround and
/run/user also solves this.
I proposed a change which does not even require --create-socketdir. There was
no comment on this and thus I will push that now so that we can do a real life test.
justus added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.
Justus: I told you several times that we are not going to change working code
for no good reason.
Except that it is not working. If it was working, then
06f1f163e96f1039304fd3cf565cf9de1ca45849
would not be necessary.
Even if your hack (I call it a hack because it does not
work with getsockname)
1/ Yes it does. It returns precisely the path that was used in bind.
2/ We only use getsockname on sockets that were given us by a service manager
like systemd, and thus those sockets would be unaffected by "the hack".
would make it, it does not solve the major problem: The
inability of creating sockets on certain file systems. THAT is the major reason
why we moved to /var/run.
Please stop conflating these things. This bug is about "dirmngr and gpg-agent
should work automatically even when GNUPGHOME is larger than sun_path". It is
not about NFS or FAT or something.
Mar 21 2017
Mar 21 2017
• werner added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.
Justus: I told you several times that we are not going to change working code
for no good reason. Even if your hack (I call it a hack because it does not
work with getsockname) would make it, it does not solve the major problem: The
inability of creating sockets on certain file systems. THAT is the major reason
why we moved to /var/run.
justus added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.
The whole IPC thing is pretty complex and adding a non-standard hack as proposed
by Justus will for sure cause breakage on some platforms.
I'm not sure why you call it a hack. I've been looking at POSIX, [0] introduces
pathname resolution, and the terms 'relative path' and 'absolute path'.
0: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13
Neither the page for connect [1], nor the one for bind [2] state that the path
used to connect/bind unix sockets must be an absolute path.
1: http: / / pubs.opengroup.org/onlinepubs/9699919799/functions/connect.html#
2: http: / / pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html#
Furthermore, my test across a wide range of UNIX implementations did not show
any issues with using relative paths.
Mar 14 2017
Mar 14 2017
• werner added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.
I agreed in T2964 (wk on Mar 01 2017, 07:31 AM / Roundup) to auto create socket directories. I would like to do that
only for a tmpfs but we can also try to do this always. Adding a inotify watch
to remove the directory is more complex and I am not sure whether this is really
needed. The other thing is simple and we could do that for 2.1.20.
The whole IPC thing is pretty complex and adding a non-standard hack as proposed
by Justus will for sure cause breakage on some platforms.
Yes, we should document /var/run recommendations in the README. I will do that
for the next release.