AC:
* Key stash is moved to a dynamic data type like the rpmts or the keyring
* The key stash is using the long KeyID
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/
You are receiving this because you are subscribed to this thread.
Key IDs (even long ones) can have collisions - especially when an attacker
tries to generate them on purpose. The right behavior is to try all keys with
matching key IDs and see if one is able to verify the signature.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm
> > In existing databases, stale references must not be left behind.
>
> This part still sounds quite vague (to me)...
Basically that means in existing databases, we need to keep updating the
indexes. Minimally, we need to update the index on package removal. If we just
drop the code, we could
Ack, this looks like the right amount of effort for such a tiny thing, indeed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-2376296072
You are receiving this because you are subscribed to this thread.
Message ID: __
> Nothing will make a long hex string particularly suitable to human
> consumption anyhow 😆
Exactly.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3321#issuecomment-2376442414
You are receiving this because you are subscribed to this t
Hmm. On a second thought: we could simply just remove the query switches for
now, and leave the db indexes to die of old age, and bury in rpm 7.0. That
preserves them for existing databases and in new ones they'll eventually just
grow empty because the data is not there. These indexes are not ex
So... that would make an AC something like:
- --pkgid and --hdrid cli switches and corresponding documentation is removed
- RPMDBI_SIGMD5 and RPMDBI_SHA1HEADER are documented as deprecated
That would let us off the hook with minimal effort, this isn't a very
interesting item from v6 perspective
Currently rpmkeys --list only give the version, release and summary of the
gpg-pubkey packages aka short key ID, creation time and issuer. There is now
way to get the fingerprint or even long key ID from RPM for the installed GPG
keys.
Make the current format more useful and also offer a long f
I'd make the second point into "rpmkeys --list uses the keyring API for
iterating the keys" - we don't want to replace gpg-pubkey db iteration with,
say, manual fs walk to do the same, this should be in the keyring, but
otherwise looks fine.
--
Reply to this email directly or view it on GitHub
Rpm indeed uses lowercase hex everywhere, and changing that would be
inconsistent / a bit jarring .
But then at least Sequoia and GPG do use uppercase so for the fingerprints (and
keyids) it would make it easier to compare to those :thinking:
I remember seeing split up fingerprints someplace b
Further musings on the topic: rpmts supports populating the keyring from either
the rpmdb or keys-in-directory, but the keyring itself is a transient in-memory
thing, only good for verifying. That was the minimal goal back then, a long
long ago. Going forward the storage part needs to be more sa
I'd encourage you to use the [shared OpenPGP certificate directory
specification](https://datatracker.ietf.org/doc/draft-nwjw-openpgp-cert-d/)
(this document hasn't yet been ratified by the IETF, but it is [part of the
current charter](https://datatracker.ietf.org/doc/charter-ietf-openpgp/)). A
OK; I put the sub projects into their own tickets and updated the todo list.
#3321 has shown that we are fine with the API of the backends as they are. So
this whole thing is a bit easier than first thought. Next step is teaching
`rpmkeys` to give some useful information on the installed keys (#
Oh... thanks for the pointer!
I saw ~/.local/share/pgp.cert.d use in sq and figured this might be intended
for cross-tool sharing, but didn't get furher.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3313#issuecomment-2376597783
You
Yup! Of course, `rpm` should have its own dedicated certificate store. But
using a common format means it is possible to use it with, e.g., `sq` using `sq
--cert-store PATH ...`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3313#i
Of course. The fs-backend puts it simply into "pubkeys" subdirectory of the
rpmdb, typically /var/lib/rpm/pubkeys/
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3313#issuecomment-2376612975
You are receiving this because you are subsc
> I wonder what's the deal with upper verses lower case hex strings. I split
> the fingerprints into groups of four and in lowercase this looks very wrong
> to me for some reason. Any opinions on that topic? Looks like RPM has always
> used lowercase in one continuous string.
In my experience m
Related to #2633, rpm currently aliases RPMTAG_PKGID to MD5 and RPMTAG_HDRID to
SHA1HEADER tags. This doesn't cut it going forward because said tags will no
longer be there.
We can sort of keep these alive by adding tag extensions that provide an
identifying hash for the package. Differentiatin
Split the pkgid/hdrid tag aliases to a separate ticket too, they're not
actually used for the database operation: #3330
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-2376129044
You are receiving this because you are
And, from there we get to something resembling an AC:
- RPMDBI_SIGMD5 and RPMDBI_SHA1HEADER indexes are not generated for new
databases. In existing databases, stale references must not be left behind.
- --hdrid and --pkgid cli switches are removed - in my >= 20 years of rpm, I've
yet to see anyb
**Describe the bug**
I'm currently working on a grammar for tree-sitter:
[tree-sitter-rpmspec](https://gitlab.com/cryptomilk/tree-sitter-rpmspec/)
If you look in the RPM spec file reference to get details about macros, I only
find sparse information. I'm trying to get macros supported correctly
Closed #3273 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3273#event-14411188114
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Fixed in
https://github.com/rpm-software-management/rpm-web/commit/0d042f64aaffddc54e301bda5e5f2eb257ca9ee7
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3273#issuecomment-2376155606
You are receiving this because you are subscribed t
>* --hdrid and --pkgid cli switches are removed - in my >= 20 years of rpm,
>I've yet to see anybody actually use these
Is the removal of these two switches settled then? Also, isn't the new #3330
related to this in a way? I.e. if we end up keeping the aliases, shouldn't we
also keep the CLI s
Well, OK, that's why you were asking for feedback in the first place (while you
also justified the removal) :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-2376168500
You are receiving this because you are subs
I also think that removing obscure functionality makes sense unless we know of
some users (and we don't here). It can always be added back in the future if
there's enough interest...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633
The PKGID and HDRID tags are not used for the index generation, or query. The
db index uses RPMDBI_SIGMD5 and RPMDBI_SHA1HEADER, which "happen to be"
equivalent to RPMTAG_SIGMD5 and RPMTAG_SHA1HEADER.
so the PKGID and HDRID tags could be removed and I think rpm would still
compile and work, some
So in other words, its two practically unused tags, practically unused
cli-switches, backed by two practically unused db indexes :facepalm: :laughing:
We could keep --pkgid and --hdrid without the indexes and just do a brute-force
search, but there seems little point in preserving this function
Oh, looking at the code here too, you're right.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-2376178133
You are receiving this because you are subscribed to this thread.
Message ID: _
Yup, makes sense now, thanks :smile: As for the first AC point:
> In existing databases, stale references must not be left behind.
This part still sounds quite vague (to me)...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633#issue
@ffesti pushed 0 commits.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3321/files/a06349ba66cb3fe8ee156029829959d1b7f82a7d..a927b9d12e218b77133418ee32d886588eaf9b64
You are receiving this because you are subscribed to this thread.
Message ID:
_
@nwalfield commented on this pull request.
> @@ -107,6 +107,22 @@ rpmPubkey rpmPubkeyLink(rpmPubkey key);
*/
char * rpmPubkeyBase64(rpmPubkey key);
+/** \ingroup rpmkeyring
+ * Return fingerprint of primary key
+ * @param key Pubkey
+ * @param fp Fingerprint data
+ * @par
OK, back to fingerprints in one piece.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3321#issuecomment-2376746515
You are receiving this because you are subscribed to this thread.
Message ID:
>From my POV this is now complete.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3321#issuecomment-2376750347
You are receiving this because you are subscribed to this thread.
Message ID: ___
@pmatilai pushed 1 commit.
31c46a044d27498c20499b4c67c53fa547819770 Document RPMDBI_SIGMD5 and
RPMDBI_SHA1HEADER as obsolete
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3335/files/4087cf232d5904aff801f92d9b69ef5f18a44052..31c46a044d27498c20499b4c67c53fa547819770
Y
These obscure switches are backed up by obsolete crypto that wont be, cannot
be, present in v6 packages. It would be possible to keep them alive by making
them point to non-obsolete data, but for that there would need to be a use-case
and users. These have neither as far as I've learned in the l
@ffesti pushed 5 commits.
5124ffb1099eab79c968d853748f002af98687bd Add rpmPubkeyPrimarykey and
rpmPubkeyFingerprint
e28395c631795f70c9efa72eb65815e2b9641b56 Rename mainkey to primarykey
d7a9b1d555c78f02970bd4d1e420b9ff545fd209 Add rpmKeyringVerifySig2 that return
the matching key
95ac178247fe
@ffesti commented on this pull request.
> @@ -107,6 +107,22 @@ rpmPubkey rpmPubkeyLink(rpmPubkey key);
*/
char * rpmPubkeyBase64(rpmPubkey key);
+/** \ingroup rpmkeyring
+ * Return fingerprint of primary key
+ * @param key Pubkey
+ * @param fp Fingerprint data
+ * @param
@ffesti commented on this pull request.
> @@ -107,6 +107,22 @@ rpmPubkey rpmPubkeyLink(rpmPubkey key);
*/
char * rpmPubkeyBase64(rpmPubkey key);
+/** \ingroup rpmkeyring
+ * Return fingerprint of primary key
+ * @param key Pubkey
+ * @param fp Fingerprint data
+ * @param
@nwalfield commented on this pull request.
> @@ -107,6 +107,22 @@ rpmPubkey rpmPubkeyLink(rpmPubkey key);
*/
char * rpmPubkeyBase64(rpmPubkey key);
+/** \ingroup rpmkeyring
+ * Return fingerprint of primary key
+ * @param key Pubkey
+ * @param fp Fingerprint data
+ * @par
40 matches
Mail list logo
