@DemiMarie pushed 1 commit.
0bd36c11c2e5d9ec1a9f79a30db29ba909cf6e7e Header signatures alone are not
sufficient
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Graceful error handling is preferred.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1807
-- Commit Summary --
*
It previously pointed to the documentation for libtool versioning.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1806
-- Commit Summary --
*
No other change.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1805
-- Commit Summary --
* https://github.com/rpm-software-management/rpm/pull/1805/commits/811724ba4a493d8853d8c58457d5197c4565d8e4;>Fix
typo: “all” not
@DemiMarie commented on this pull request.
Thanks for the feedback @pmatilai.
> @@ -426,6 +426,11 @@ static int pgpVersion(const uint8_t *h, size_t hlen,
> uint8_t *version)
return 0;
}
+int pgpSignatureType(pgpDigParams _digp) {
+assert(_digp->tag == PGPTAG_SIGNATURE);
That is a
@DemiMarie pushed 1 commit.
17c93c31eceed4cd9a3e78385756f4804c047f50 verifySignature(): package signatures
must be PGPSIGTYPE_BINARY
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
For reference:
* https://github.com/rpm-software-management/rpm/blob/master/lib/rpmtypes.h#L40
* https://github.com/rpm-software-management/rpm/blob/master/lib/rpmtypes.h#L52
Looks like we also need to make sure that the conversion from i64 to u32 and
back is correctly handled in the code.
--
Alright. I've just force-pushed this with a new spin based on the idea of
simply using `SOURCE_DATE_EPOCH` and having a "fake clock" sitting under the
relevant parts.
I went with a central static clock rather than a per-transaction one in case a
consumer is performing multiple transactions.
@jeamland pushed 1 commit.
d00d9cbf9715f53f903a6cf7e6c33697d4f293b2 Allow an optional "fake clock" for
deterministic timestamps
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Hello,
I'd like to propose to replace RPM's built-in PGP support with Sequoia.
Sequoia is an OpenPGP implementation written in Rust. We have released
Sequoia 1.5 earlier this week, which is the first version released under
the LGPL2+.
Our low-level crate, sequoia-openpgp, features an
Is it ok for you if I make `%{define foo bar}` work? Currently, `%{define foo
bar}` is the same as `%define`, which is kinda sad. I'd rather have it behave
like `%{define:foo bar}`.
Can I also change `%{define:foo bar}` to not use that super weird free-field
parser? I'd prefer to make it work
@pmatilai commented on this pull request.
> @@ -566,7 +566,9 @@ static rpmRC verifyDigest(struct rpmsinfo_s *sinfo)
static rpmRC
verifySignature(rpmKeyring keyring, struct rpmsinfo_s *sinfo)
{
-rpmRC res = rpmKeyringVerifySig(keyring, sinfo->sig, sinfo->ctx);
+rpmRC res = RPMRC_FAIL;
@pmatilai commented on this pull request.
> @@ -426,6 +426,11 @@ static int pgpVersion(const uint8_t *h, size_t hlen,
> uint8_t *version)
return 0;
}
+int pgpSignatureType(pgpDigParams _digp) {
+assert(_digp->tag == PGPTAG_SIGNATURE);
Imagine for a moment what life would be like
I keep forgetting about `SOURCE_DATE_EPOCH`. Makes me wonder if we need any
other mechanism for activating the fake clock at all :thinking: We have a whole
pile of related macros which are on/off toggles, so maybe this should suite
although I'm not quite sure every single addition really
So have something like a `__override_timestamp` macro that, if set, would act a
base timestamp that could be used as RPMTAG_INSTALLTID and then you could do
something like singular increments of that timestamp as the RPMTAG_INSTALLTIME
values?
And then `SOURCE_DATE_EPOCH` could be shunted into
So have something like a `__override_timestamp` macro that, if set, would act a
base timestamp that could be used as RPMTAG_INSTALLTID and then you could do
something like singular increments of that timestamp as the RPMTAG_INSTALLTIME
values?
And then `SOURCE_DATE_EPOCH` could be shunted into
That's pretty much what I was thinking: Lua's pattern matching may have been
less capable back when this was added, but I don't know. People are more
familiar with regex but there doesn't seem to be a huge market for it.
Minimally resurrecting the rex extension is just about four lines of
This may well make your case "work" for the same reason it appeared to work
before the commit introducing the regression, but it's not right and breaks
other cases. Thanks for trying though :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Closed #1804.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1804#event-5496192560___
Rpm-maint mailing list
19 matches
Mail list logo
