Re: [Rpm-maint] [rpm-software-management/rpm] Axe defunct Lua rex extension (PR #1797)
@Conan-Kudo approved this pull request. -- 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/1797#pullrequestreview-790035854___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Support glibc-hwcaps in rpm (Issue #1812)
"dancermak 5 days ago by dancermak | Reply This sounds very intriguing! I have a few notes about this: you might be interested in this (sadly stalled) upstream PR: https://github.com/rpm-software-management/rpm/pull/1035 which adds better detection of the currently running microarchitecture once rpm gains the ability to automatically generate subpackages (https://github.com/rpm-software-management/rpm/pull/1485), this could be completely automated" https://lists.fedorahosted.org/archives/list/de...@lists.fedoraproject.org/message/5GAPNLIJGNCBZCP2L2CDY6I6TZLZD6EB/ -- 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/issues/1812___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use lua_replace instead of lua_rotate (PR #1811)
I just looked at the commit that changed the requires from 5.2 to 5.3, and that one did not include the INSTALL part. Sorry. Updated and force-pushed. -- 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/1811#issuecomment-952043417___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use lua_replace instead of lua_rotate (PR #1811)
@mlschroe pushed 1 commit. 53da480b245f0e1dfb1d518a2cdc8373a47b52d4 Use lua_replace instead of lua_rotate -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1811/files/11017b995b1ab14d5cefc96fc605b3082f87f064..53da480b245f0e1dfb1d518a2cdc8373a47b52d4 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use lua_replace instead of lua_rotate (PR #1811)
Fine with me, but please update the Lua version in INSTALL too. -- 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/1811#issuecomment-951932385___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow an optional argument for the %verbose macro (#1791)
Thanks! -- 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/1791#issuecomment-951925391___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow an optional argument for the %verbose macro (#1791)
Merged #1791 into master. -- 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/1791#event-5520530521___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Add shorthand syntax for default macro values (#1756)
Ohh, non-emptyness instead of plain definedness? Like in most shells:
`${foo-bar}` versus `${foo:-bar}`...
--
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/issues/1756#issuecomment-951879592___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Use lua_replace instead of lua_rotate (PR #1811)
lua_rotate works but is somewhat the wrong tool if we just want to set a specific stack element. Use lua_replace instead. This has the added advantage that the code works again with lua version 5.2 (not that it matters much). You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1811 -- Commit Summary -- * https://github.com/rpm-software-management/rpm/pull/1811/commits/11017b995b1ab14d5cefc96fc605b3082f87f064;>Use lua_replace instead of lua_rotate -- File Changes -- M configure.ac (2) M rpmio/rpmlua.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1811.patch https://github.com/rpm-software-management/rpm/pull/1811.diff -- 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/1811 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow an optional argument for the %verbose macro (#1791)
I added the documentation and rebased the commit to the new macro code. -- 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/1791#issuecomment-951846887___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild --target is not properly passed to configure (Issue #1810)
Ok so then platform/$platform/macros should override these macros in the
global macros file then?
%_build %{_host}
%_build_alias %{_host_alias}
%_build_cpu %{_host_cpu}
%_build_vendor %{_host_vendor}
%_build_os %{_host_os}
%_host i686-pc-linux-gnu
--
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/issues/1810#issuecomment-951828891___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild --target is not properly passed to configure (Issue #1810)
Yup, rpm's --target and configure's --target mean two entirely different things, and passing rpm's idea of --target to configure was always wrong. That's why it was removed. If you're actually building a cross-compiler then pass --target to configure explicitly from the spec. -- 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/issues/1810#issuecomment-951799067___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild --target is not properly passed to configure (Issue #1810)
Closed #1810. -- 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/issues/1810#event-5519534289___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Add shorthand syntax for default macro values (#1756)
More thinking out loud, `%{foo|bar}` as a shorthand for the actual expression
(`%["%{?foo}" || "bar")
--
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/issues/1756#issuecomment-951765401___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild --target is not properly passed to configure (Issue #1810)
But that's wrong. Configure's --target option is meant to be used to define the generated arch when building a cross compiler. E.g. if you want to build a cross compiler for aarch64 that runs on your x86_64 host. But the generated rpm that contains the cross compiler will still be x86_64. Note that this is about building a cross compiler, not using one. I.e. configure is not in "cross compilation" mode if --target is used. See: https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html -- 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/issues/1810#issuecomment-951745037___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow the transaction ID and installation time to be overridden (PR #1803)
@pmatilai commented on this pull request. > @@ -1296,3 +1296,30 @@ rpmtxn rpmtxnEnd(rpmtxn txn) } return NULL; } + +#define FAKE_CLOCK_INITIALIZED (1<<0) +#define FAKE_CLOCK_ACTIVE (1<<1) + +static int _fakeClockState = 0; +static time_t _fakeClock = -1; bogoClock would work for me too :grin: -- 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/1803#discussion_r736291605___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow the transaction ID and installation time to be overridden (PR #1803)
@pmatilai commented on this pull request. > @@ -1296,3 +1296,30 @@ rpmtxn rpmtxnEnd(rpmtxn txn) } return NULL; } + +#define FAKE_CLOCK_INITIALIZED (1<<0) +#define FAKE_CLOCK_ACTIVE (1<<1) + +static int _fakeClockState = 0; +static time_t _fakeClock = -1; + +rpm_time_t rpmtsGetTime(time_t step) Dunno, this seems quite nice and simple to me, for the purpose. Remember this is an internal-only API which we can change at will if the need rises, but at the moment I don't see a need for any further API on this. -- 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/1803#discussion_r736290223___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow the transaction ID and installation time to be overridden (PR #1803)
@pmatilai commented on this pull request. > @@ -1296,3 +1296,30 @@ rpmtxn rpmtxnEnd(rpmtxn txn) } return NULL; } + +#define FAKE_CLOCK_INITIALIZED (1<<0) +#define FAKE_CLOCK_ACTIVE (1<<1) + +static int _fakeClockState = 0; +static time_t _fakeClock = -1; It's not a real clock and the values don't even remotely resemble what you'd get with a real one, so logic says it must be a fake one then :sweat_smile: "synthetic" might be okay as a name but it's on the long side, ditto with "artificial". But considering this is buried deep inside rpm, it hardly matters what we call it. -- 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/1803#discussion_r736287274___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document that using assert() is frowned upon (PR #1807)
Yup. These kind of reasons are why I don't want any "assert is evil" written down in our guidelines: it's a tool like any other and has it's uses, but public API input checking is not one of those. -- 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/1807#issuecomment-951624026___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
Very well then. Thanks a lot for fixing all these lose ends I left around! -- 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/1809#issuecomment-951620460___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Porting RPM to Sequoia PGP
Michael Schroeder writes: > On Mon, Oct 25, 2021 at 05:32:38PM +0200, Justus Winter wrote: >> Michael Schroeder writes: >> >> > On 10/21/21 18:12, Justus Winter wrote: >> >> First, I think replacing RPM's point solution with a general purpose >> >> implementation will improve correctness. Robust signature verification >> >> requires canonicalization of the issuing certificate, which is tricky >> >> [0], [1], [2]. >> > >> > Wait, those links don't say why canonicalization is required. What's >> > the attack vector? Do you have other pointers? >> >> Canonicalization is required before a certificate can be safely used for >> any operation. OpenPGP certificates are compound structures made out of >> packets bound together by signatures. Canonicalization requires several >> steps, among them re-ordering out-of-place packets, deduplicating >> packets, checking signatures (and embedded signatures for signing >> subkeys), reasoning about signature and key lifetimes, and revocations. > > Yes, except that rpm needs just a very limited subset of this. No > chain of trust, no revokations, and so on. It basically needs what > 'gpgv' is providing: it must check a signature against a set of > trusted public keys. gpgv absolutely does certificate canonicalization. And it does a lot of the things that I have mentioned. I think what you are saying is that RPM expects certificates to be canonicalized before they are fed to RPM. But, that is exactly what led to CVE-2021-3521. https://access.redhat.com/security/cve/cve-2021-3521 >> That unfortunately is true. Or rather, it was. OpenPGP's development >> picked up speed, we recently formed a design team that is creating a >> proposal for the next RFC, and have produced a new draft just last week: >> >> https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/ >> >> Relevant changes for RPM include: New key packet types, new hash >> algorithms, EdDSA over Ed448, new fingerprint format, maybe new >> signature packet types. > > Yeah, that's the old rfc Werner has been working on the last 6 years. > I hopt it finally gets out of the "draft" status. (Actually, it's more > imporatant to us what features gpg already provides. So we already > implemented ed25519 even if it is still only in a ietf draft.) No, that is not the old RFC that Werner has been working on. The document that Werner worked on is https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ It is true that a lot of changes that were in RFC4880bis were cleaned up, improved, and merged into the openpgp-crypto-refresh. But, in contrast to RFC4880bis, the openpgp-crypto-refresh has been written by the working group's design team and represents a broad consensus among active OpenPGP implementations. (Disclaimer: I'm part of the design team.) Justus signature.asc Description: PGP signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
