net-libs/libmicrohttpd: add support for 'verify-sig' USE flag (alternative) #34994
Conversation
Signed-off-by: Karlson2k (Evgeny Grin) <k2k@narod.ru>
Signed-off-by: Karlson2k (Evgeny Grin) <k2k@narod.ru>
Karlson2k
changed the title
Pull Request assignmentSubmitter: @Karlson2k net-libs/libmicrohttpd: @Karlson2k, @gentoo/proxy-maint Linked bugsNo bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
gentoo-bot
added
new package
|
This implementation does not store the signing keys inside gentoo git. The keys are downloaded. |
Pull request CI reportReport generated at: 2024-01-24 21:23 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
| S="${WORKDIR}" | ||
|
|
||
| LICENSE="public-domain" | ||
| SLOT="${PV}" |
There was a problem hiding this comment.
How does this having a live version even remotely make sense, when you explicitly require a specific slot from the package?
There was a problem hiding this comment.
Sorry, I don't understand the question.
Live version resides always in the same slot number 999999 and the key in this slot matches the latest version of the libmicrohttpd package. The key could be changed, but should always match the current latest libmicrohttpd version. I don't see what's wrong with this combination.
I can remove this file from this PR if it is a problem.
There was a problem hiding this comment.
The live version could be used simultaneously with other versions. That's why it has a slot.
There was a problem hiding this comment.
But no version will ever use the live version because every version will need to depend on non-live version.
There was a problem hiding this comment.
Except live versions, which could depend on live version of another package.
There are a lot of such packages in the tree, for example dev-util/pkgcheck or dev-util/pkgdev.
That's the idea of this keyring.
There was a problem hiding this comment.
How are you going to use the live version of the keyring if live versions, quite obviously, don't come with signed release tarballs?
There was a problem hiding this comment.
To be precise:
I didn't want to implement the keychain for real "live" library version. Actually my idea was to provide a simple way to check whether the upstream keys changed (when signature would fail for the new release) or something wrong with downloaded file. It should be easy to quickly check the new library release against 9999 keys and if it succeed, update the openpgp-keys- package.
In practice I don't need this file as I would know how and when the upstream signature keys are updated. It is more for others who will need to update/use these keys in case if I would not update this ebuild for whatever reason.
So I can remove the 9999 version completely, add more comments explaining my idea to the ebuild or comment out "live" part in full (so someone would be able to restore/re-use it for the latest keyring download).
Please let me know what is the best way for you.
|
If it is a problem, I can remove the 9999 file. If needed, I can remove ebuild content for 9999 version. However, I think it's nice to have keyring version that it always valid for the latest upstream. |
The PR adds support for
verify-sigfor libmicrohttpd.The relevant "keys" package is added as well.
The upstream updates release signature keys from time to time. To support different keys for different versions, the slotting is implemented in the sec-keys/openpgp-keys-libmicrohttpd package.
This is an alternative implementation of PR #34772 as requested here.