mkheader has CFLAGS_FOR_BUILD since libassuan 2.5.4.
gost-s-box has so since libgcrypt 1.9.0.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 15 2021
Making this task up to HIGH priority, so that people can easily find this change in 2.3.0.
Done for gpa.
Please test.
Done for pinentry.
This task includes multiple issues: two sub-tasks and how-to-use remotely.
Two tasks had been fixed already.
The last one was documented here.
So, closing.
Thank you. Merged and pushed.
Apr 14 2021
Thank you for applying the provided changes!
Applied and pushed.
@werner No problem. Just go ahead.
Apr 13 2021
In T5394#145082, @werner wrote:Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.
In T5393#145158, @werner wrote:Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.
Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.
@gniibe: If you don't mind I would like to steal task this from you. I have noticed a few things which could get a little code refresh in addition to the fixes.
There is couple of issues that I did not want to propose a patch for, but might require some attention:
Error: IDENTICAL_BRANCHES (CWE-398): [#def28] [important] gnupg-2.3.0/common/tlv-builder.c:353: identical_branches: The same code is executed regardless of whether "tag < 31" is true, because the 'then' and 'else' branches are identical. Should one of the branches be modified, or the entire 'if' statement replaced? # 351| (void)constructed; /* Not used, but passed for uniformity of such calls. */ # 352| # 353|-> if (tag < 0x1f) # 354| { # 355| buflen++;
There are also couple of reports about the function default_homedir(), which is supposed to return const char * but in reality, it sometimes allocates memory while callers do not expect it so they do not free:
Error: RESOURCE_LEAK (CWE-772): [#def11] gnupg-2.2.27/common/homedir.c:477: alloc_fn: Storage is returned from allocation function "default_homedir". gnupg-2.2.27/common/homedir.c:477: var_assign: Assigning: "newdir" = storage returned from "default_homedir()". gnupg-2.2.27/common/homedir.c:488: noescape: Resource "newdir" is not freed or pointed-to in "make_absfilename". gnupg-2.2.27/common/homedir.c:490: leaked_storage: Returning without freeing "newdir" leaks the storage that it points to. # 488| the_gnupg_homedir = make_absfilename (newdir, NULL);; # 489| xfree (tmp); # 490|-> } # 491| # 492|
The PKCS#15 support has meanwhile received a major update. Thus we need to test with the other cards again. If there is something special for to do for a certain task, a new subtask should be created.
Should be done
Thank you. The initial run was against olderer version of gnupg (and had one issue in g10/keyedit.c -- see the new patch with fixup). Now I ran it against the version 2.3 and there are couple of more issues to be fixed (rebased on top of already applied changes and the previous commits).
Done for 2.2. and 2.3.
Ok.
But`CFLAGS_FOR_BUILD` not mentioned in build rule for mkheader
In T5217#144071, @ikloecker wrote:Except for T5341: gpgconf does not list default_pubkey_algo pseudo option anymore, this should be done.
Applying changes is fixed.
Reopening because at least a debug build of Kleopatra crashes with an assertion when applying changes.
Yes I agree it makes sense to have this as an explicit setting to cover both use cases.
This really depends on the use case. Some people want to extend the lifetime of their whole key. Others explicitly use a long-lived primary key with short lived subkeys. A possible heuristic for the default behavior to propose to the user would be to check whether the current expiry dates of primary key and subkeys are the same or not. The user could still change this proposed default in the dialog that's anyway shown for the new expiry date.
Yes the other one was a duplicate, somehow my search didnt find this and I thought I had forgotten to open the issue.
Done in 2.3.0.
Done in 2.3.0.
Done in 2.3.
Thank you.
Thank you. Applied and pushed.
I'm sorry I disappeared on this issue for two weeks; I just got reminded of it by seeing the e-mail with the status change. I've updated to the latest gcrypt (which is the commit with the patch, now pushed to the repository) and was able to upload this to Apple without it being flagged; thanks!
Thank you. I'll take care of this.
Regarding your patch, I am personally not opposed to it, but apparently Debian’s policy says the library/module should be called scute while Gentoo’s policy says it should be called libscute… What should an upstream developer do?