I would expect migration to happen this way:
* a dnf repo has only rpms with only one old signature
* dnf and rpm and distribution-repo-keys package or dns repo metadata for
offering new keys are updated to support the new signature format and include
the new key
* a release cycle happens so peo
@pmatilai pushed 2 commits.
7df36ba7ba370f72f93554c1863d855a0ed5856d Run all signing tests with runroot
since we now can
1d53115a6310a9cfb4b5a58fd71c5e0c1487e96c Sanitize rpmsign --addsign/--delsign
output
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3424/files/d
@JanZerebecki
This work is meant to create the conditions to move to new signatures over time
while retaining backwards compatibility.
A draconian policy that does not contemplate the possibility of getting an RPM
with unknown signatures would make any transition impossible. I am sure it
shou
@dmnks approved this pull request.
Looks good, I've made a little fixup commit, see the message for details.
There's a conflict in one test on master now so please resolve and then feel
free to merge this one.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softw
Another related change is that we'll call header+payload signatures and
digests "Legacy" from here on. Rpm v4 header signatures will be
called legacy too but maybe not just yet.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3385#iss
Merged #3427 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3427#event-15148681747
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Merged #3424 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3424#event-15149992339
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@pmatilai pushed 2 commits.
be716979449003f17fc71d523bd2a2b654eef774 Run all signing tests with runroot
since we now can
9d6dd4609e86efdb58d6d610e9b859e5debf0347 Sanitize rpmsign --addsign/--delsign
output
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3424/files/1
Merged #3423 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3423#event-15145540716
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@dmnks commented on this pull request.
>
-cp ${ORIG} "${RPMTEST}"/tmp/
-run rpmsign --key-id 4344591E1964C5FC --addsign ${NEW} > /dev/null
-cmp -s ${ORIG} ${NEW}; echo $?
-run rpmsign --delsign ${NEW} > /dev/null
-cmp -s ${ORIG} ${NEW}; echo $?
+runroot_other cp ${ORIG} /tmp/
+runroot rpmsign
Merged #3428 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3428#event-15145843673
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
All the distros build it as a dynamic library. It should also be available on
Ubuntu, so you don't need to roll your own.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3430#discussioncomment-11164063
You are receiving this becaus
> Hmm, I found one leftover /dev/null redirect in my local tree but not the
one you mentioned, I wonder if this is GH playing tricks... anyway, fixed the
one I found 😅
Yeah, I realized I had commented on an outdated commit so deleted the comment
right away :sweat_smile: Juggling too many branc
ok, sorry if i get it like it was too high. I'm not english native and maybe
your answer was not so haughty as i feel it was.
So there is nothing to explain how we are supposed it to work and nothing will
be done in this way. Ok, thank you and have a good rest.
--
Reply to this email directly o
Doh :sweat_smile:
Thanks for the patch.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3428#issuecomment-2459244331
You are receiving this because you are subscribed to this thread.
Message ID:
> We don't generally endorse or support static linkage because it's nothing but
> a headache.
But I read the docs of lua.org, there's no guide about compile lua to a dynamic
library.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussion
@ffesti converted this issue into discussion #3431.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3420#event-15143634325
You are receiving this because you are subscribed to this thread.
Message ID:
__
This adds the following to verbose mode signature verification:
- OpenPGP string to all signatures (these are not raw DSA/RSA/etc but OpenPGP)
- Header+payload signatures and digests are now prefixed Legacy to make it
clear what they are
Both needed to pave way for the multiple signature stuff.
Y
@pmatilai How do we decide when a package "fails" verification with
multiple signatures? Would we have a policy tunable? Some kind of indicator as
a "primary" signature? Or something else?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issu
@Conan-Kudo the simplest policy is that signatures must all verify (why would
you put multiple of them otherwise?).
The tricky part is how to handle signatures you do not understand, and I think
the simplest policy, again, is to ignore those.
Note, I am not saying you should ignore signatures
Hmm, I found one leftover /dev/null redirect in my local tree but not the one
you mentioned, I wonder if this is GH playing tricks... anyway, fixed the one I
found :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3424#issu
> @pmatilai How do we decide when a package "fails" verification
with multiple signatures? Would we have a policy tunable? Some kind of
indicator as a "primary" signature? Or something else?
Hmm, I thought it was in the description as it's been discussed elsewhere
but apparently not - will fix
Also note that dnf (or otherwise) repositories are way out of scope and topic
here, this is strictly an rpm level matter. How multiple signatures are dealt
with on repo level is a repo tooling headache to be discussed elsewhere.
--
Reply to this email directly or view it on GitHub:
https://git
> But, if we can't be trusted to decode base64 then how are we expected
to read the rest of the rpm? That's like being too afraid to leave the
house because something bad might happen.
The point was not about the correctness of our implementation of base64, but
that the format should have only
> @Conan-Kudo the simplest policy is that signatures must all verify (why
would you put multiple of them otherwise?).
>
Multiple signatures aren't necessarily for users installing to process, so
it would make sense to ignore them in that case. For example, the signatures
may be used to indica
One important point of my suggestion is that the list of keys that are
associated with a repo is signed and verifiable with the same list, but is
distinct from the keys that are trusted to sign repos. Trusted keys are a
superset of keys used in a repo.
This makes verifying parts of a repo more
@pmatilai pushed 2 commits.
1a88fff24c9e21e860e3a0e3d58bb282dbefaad8 Add "OpenPGP" to all signature
verification related messages
106a0140b5fa166a7a24c87248239d79a6072053 Call header+payload signatures and
digests legacy
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pu
@dmnks pushed 1 commit.
4f29655480dbfdf6746a477901a717da764d6e15 fixup! Run all signing tests with
runroot since we now can
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3424/files/a3224a4ac684192ede1783224897f60b92fb2bab..4f29655480dbfdf6746a477901a717da764d6e15
Yo
I disagree as explained above. If there is a sig you do not understand it
should fail the rpm. If you do not have a key for one it should fail. Sigs for
all specified keys need to always be present and to be in the correct order
otherwise fail.
--
Reply to this email directly or view it on Gi
(This implies different dnf repos with different key sets can coexist on the
same system. So you could also add a new repo to an installation, stop updating
the old repo, and at some point remove the old repo from this installation.)
--
Reply to this email directly or view it on GitHub:
https:
30 matches
Mail list logo
