Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

@ddiss fsverity would also be suitable. If you go with this approach, I recommend also including the total length of the payload in the (signed) header, to avoid vulnerabilities where extra data somehow doesn’t get hashed. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

Do you plan on doing streaming cryptographic verification? See . -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Rethinking RPM architecture support (Discussion #2060)

100% agree. That said, AMD really ought to go the Nvidia route of having an intermediate bytecode. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2060#discussioncomment-8741103 You are receiving this because you are subscribed

Re: [Rpm-maint] [rpm-software-management/rpm] Support for running tests on a different machine (Discussion #2884)

@pmatilai I was referring to `%check` in spec files, _not_ RPM’s own test suite (though that would be useful too). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2884#discussioncomment-8374826 You are receiving this because you

[Rpm-maint] [rpm-software-management/rpm] Support for running tests on a different machine (Discussion #2884)

To the best of my understanding, cross-compilation currently is incompatible with running test suites, unless one uses QEMU or other pure-software emulation mechanisms. These cause problems with code that depends on CPU features. At the same time, the rise of languages such as Rust and C++,

Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)

> > @kanavin Are all of the RPMs used also built locally? In that case > > disabling signature checking is fine. > > Yes of course. Yocto is fully self-contained, except for the bootstrap items > mentioned above. It builds components from source, then makes its own > packages from the

Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)

The reason for getting rid of the internal OpenPGP parser is that it turns out to have security vulnerabilities that are exploitable if someone does `gpg2 --export --armor -o s.asc FINGERPRINT && rpmkeys --import s.asc`. Patching these vulnerabilities isn’t practical, as it would require a

Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)

@kanavin Are all of the RPMs used also built locally? In that case disabling signature checking is fine. FYI, both rustc and clang are native cross compilers with support for multiple targets. The same rustc and clang that are used to compile programs for the build environment can also be

Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)

> > > So Yocto can accept that regression in package security, we'll make sure > > > to place warnings where appropriate. > > > > > > Another option would be to use the host system’s RPM for verifying the > > packages. > > Using host distro tools in cross-compilation builds is problematic, as

Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)

> > > We can live with rpm verification disabled too. > > > > > > This is a terrible idea from a security perspective. > > In embedded linux world, production systems are rarely if ever updated from > package feeds by a package manager. Rather, the whole root filesystem gets > overwritten

Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)

> So outsourcing the crypto to external gpg executable would be very welcome. This isn’t going to happen because spawning an external program breaks in too many situations. > We can live with rpm verification disabled too. This is a terrible idea from a security perspective. -- Reply to this

Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)

It does not @pmatilai, but many people are uncomfortable with situations where reporting a bug via the proper channels (public GitHub issue) means publicizing a 0day vulnerability in their own product. They would prefer if security problems in their product caused by upstream bugs were

Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)

@pmatilai I, and I suspect @rhdesmond as well, are not comfortable creating a situation where a bug is not a security vulnerability in RPM, but is a security vulnerability in the downstream project. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)

I think @rhdesmond is in the situation of needing to process RPM databases that come from untrusted container images. These databases might be malicious and might try to exploit a bug in librpm to compromise the vulnerability scanner. Such a bug would arguably be out of scope for librpm

Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)

Nope. Is there a reason that using librpm is not an option? If there is, you will need to reverse-engineer the format and keep pace with whatever librpm does. Could you compile librpm to WebAssembly and create a new WebAssembly runtime for each container? That could be a solution to

Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)

@andrewclausen The Sequoia backend should process revocation certificates correctly. The internal backend does not, which is one of multiple reasons it is deprecated. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Replace fakechroot with proper container technology (PR #2559)

@dmnks There is a FUSE implementation of OverlayFS that also supports the BSDs. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Create content handler plugin hook (PR #2416)

I don’t consider any sort of streaming unpacking to be viable with the v4 file format. For it to be viable with v6, v6 would need to use some sort of Merkle tree to allow incremental verification of the signature. One option would be to pack a bunch of hashes (as binary, not hex) into a

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro '%-x**' containing all occurrences of the flag '-x' (PR #2449)

@pmatilai what about quoting each argument separately, or making them available as a Lua array? IMO any macro this complex should probably be written in Lua. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2449#issuecomment-1565725576

Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: How to get subkey fingerprint? (Issue #2516)

@jrohel I suggest adding this feature. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2516#issuecomment-1564670277 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

> Is there a plan to add support for ASCII armored PGP signatures to librpm's > internal implementation? Highly unlikely. The internal implementation is only for backwards compatibility with environments that for some reason are not willing to use the Sequoia implementation. It has known

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group info reliable operation across chroot (PR #2503)

What about users and groups that are not in `/etc/passwd` or `/etc/group`? Those won’t work with this design. IMO the only way to get everything right is to either reimplement glibc nsswitch (yuck) or to fork/exec a subprocess and have _that_ chroot before it makes any user or group lookups.

Re: [Rpm-maint] [rpm-software-management/rpm] RPM package invariants? (Discussion #2025)

Anything starting with a `-` should probably be rejected because option injection is a thing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2025#discussioncomment-5690432 You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] Verification of PAYLOADDIGESTALT is broken (Issue #2486)

@dralley RPM does not decompress the payload when verifying signatures and digests. That would massively increase its attack surface. Therefore, failing to verify `PAYLOADDIGESTALT` is expected. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RPM package invariants? (Discussion #2025)

v4 cannot require this because of backwards compatibility. v6 does require it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2025#discussioncomment-5561362 You are receiving this because you are subscribed to this thread.

Re: [Rpm-maint] [rpm-software-management/rpm] Fix an "expected expression" error (PR #2434)

@DemiMarie commented on this pull request. > setmeta: + ; /* Empty statement for label */ /* Special files require path-based ops */ ```suggestion setmeta:; /* Special files require path-based ops */ ``` -- Reply to this email directly or view

Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)

If RPM goes this route, it should keep a small part of the internal parser. Specifically, it should keep the checks that the signature is a single OpenPGP signature packet of the correct type. This is a workaround for a known and unfixed denial-of-service vulnerability in GnuPG that I

Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)

What about adding per-file architectures, and keeping the legacy "arch" purely for compatibility with old tools? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5221608 You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] RPM package invariants? (Discussion #2025)

[`rpm-oxide`](https://github/QubesOS/qubes-rpm-oxide) should check all of them. The ones that it does not check are limitations of the tool. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2025#discussioncomment-5210810 You are

Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)

You’re welcome. What about padding between one tag and the next? Personally, I think that using a dribble for the padding is a fine, _provided_ that: 1. No other tags are allowed in the dribble. 2. Regions are checked to be consistent. 3. The padding is _required_ to be in the dribble. 4. The

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

To add to this: Plugins should not get access to content that has not been verified yet. That means creating a new method of cryptographic verification, one that allows streaming verification of the data. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)

Would checking that padding is zeroed be a part of this? What about banning dribbles from the signature header? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-4908760 You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

Also check that I/O errors (`EIO`, `ENOMEM`, `ENOSPC`, `EACCES`, `EPERM`, etc) result in a non-zero exit code. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1419777020 You are receiving this because you are subscribed

Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)

Could the signature also cover something indicating the package version? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-4824257 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Document %setup and %patch, officially deprecating %patchN (PR #2352)

@DemiMarie commented on this pull request. > +It accepts a number of options. With the exception of `-P`, they are merely +pass the option down to the `patch` command. ```suggestion It accepts a number of options. With the exception of `-P`, they are merely passed down to the `patch` command.

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Use Python Stable ABI for the bindings (Issue #2345)

An alternative would be to use CFFI. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2345#issuecomment-1379331440 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: optional one-shot/cached macro expansion (#1155)

What about rewriting the macro in Lua and stashing the result in a Lua global variable? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1155#issuecomment-1369167626 You are receiving this because you are subscribed to this thread.

Re: [Rpm-maint] [rpm-software-management/rpm] cannot use lua libraries in rpm4.14 and later (Issue #2309)

> You still haven't explained what you're actually trying to do, "use lua" or > "use library x" doesn't explain anything at all. > > What is the problem you are solving with these tools? Like said, rpm macros > are nothing but a fancy text pre-processor. Complicated programming doesn't >

Re: [Rpm-maint] [rpm-software-management/rpm] unable to import GPG keys if bit 7 "critical" of the subpacket type is set (Issue #2323)

Please report this to SUSE. RPM 4.14.3 won’t be getting updates from upstream. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2323#issuecomment-1347608828 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] cannot use lua libraries in rpm4.14 and later (Issue #2309)

For libraries written in Lua, you could copy the code into your spec file. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1332310497 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for generating buildinfo file as subpackage (#1532)

@DemiMarie commented on this pull request. > +# in this Software without prior written authorization of the copyright > holder. +# + +set -e -o pipefail + +getos() { +# shellcheck disable=SC1091 +test -r /etc/os-release && . /etc/os-release +if test -z "${ID}"; then +

Re: [Rpm-maint] [rpm-software-management/rpm] Return better error codes from the crypto backends (Issue #2127)

@nwalfield: That is fine. That said, please understand that v5 signatures need to be changed to be unambiguous with v3 signatures, since v3 signatures cannot be unconditionally rejected. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Return better error codes from the crypto backends (Issue #2127)

@nwalfield: why are v3 signatures considered insecure? IIRC they are still used to sign RPM packages. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2127#issuecomment-1320628908 You are receiving this because you are subscribed to

Re: [Rpm-maint] [rpm-software-management/rpm] rpmkeys type confusion fails when using the sequoia backend (Issue #2272)

> The test is much too strict. Using the Sequoia backend, this fails as follows: > > ``` > $ ./rpmkeys --import ./tests/testing/data/keys/type-confusion.asc > warning: Certificate 4344591E1964C5FC: > Policy rejects subkey 185E6146F00650F8: No binding signature at time > 2022-11-09T15:08:19Z >

Re: [Rpm-maint] [rpm-software-management/rpm] Fix some type confusion bugs in the internal OpenPGP implementation (PR #2242)

@DemiMarie pushed 3 commits. 01c32b20550ca866869d574e73c45dc6ddf125e5 Avoid type confusion when verifying signatures 8afe572424b6b6a3526de6373f2b1b51044274b1 Check packet types of signatures and public keys d9f6fcb91fdb82b07afdaf1b6e82533755f627c3 Reject multiple PGPTAG_PUBLIC_KEY packets

Re: [Rpm-maint] [rpm-software-management/rpm] Add rpm-sort utility for sorting RPM versions (PR #2249)

> I can see how grub* needs such a thing, but I don't really see why this > should be in rpm itself. It's not a particularly common use-case AFAICS. I had to hand-roll something similar when figuring out which was the most recent VM kernel package I had installed in my dom0. -- Reply to this

Re: [Rpm-maint] [rpm-software-management/rpm] Fix some type confusion bugs in the internal OpenPGP implementation (PR #2242)

@DemiMarie pushed 3 commits. ddb8b20e8e8822045eaf5da33b6ec0cf6361be04 Avoid type confusion when verifying signatures f59638fd2e879494ba57fd9f2dc48dfe9e58a90f Check packet types of signatures and public keys e0c93993fe673f6bc8103fc87a4e2c6f3f5c38f9 Reject multiple PGPTAG_PUBLIC_KEY packets

Re: [Rpm-maint] [rpm-software-management/rpm] cmake minimum version requirement for rpm? (Discussion #2248)

It should be possible to build on Debian stable. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2248#discussioncomment-3967934 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] unreproducible `rpmdb.sqlite-shm` (Issue #2219)

> It'd be nicer of course if rpm had a supported procedure to "park" databases > for this kind of thing. --rebuilddb with some special flag maybe. `--rebuilddb` is much heavier than just a single SQL command. Perhaps `--parkdb`, along with a corresponding C API function? -- Reply to this

Re: [Rpm-maint] [rpm-software-management/rpm] Add a rudimentary "make dist" target (61bb33e)

@pmatilai does using a build directory that is outside of the source directory (something like `~/repos-build/rpm`) help? IIRC this is best practice for at least some build systems. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Distinguish between trusted and untrusted signatures and keys. (PR #1993)

@DemiMarie pushed 7 commits. a8da0bbd6ff038a7c19e6a71c3698df27da0f060 Check that alg is NULL, not that pubkey_algo is 0 6ea06fc979d1b3d56467c4f1060d55209614cfb0 Only store packets that are followed by signatures ca0fa90d5aabe608a84b8bddc1911a93a4e28706 Improve pgpVerifySelf() API

[Rpm-maint] [rpm-software-management/rpm] Fix some type confusion bugs in the internal OpenPGP implementation (PR #2242)

These can cause segfaults; see the included test cases for details. I know the internal parser is deprecated, but hopefully a segfault-triggering bug is still worth fixing. You can view, comment on, or merge this pull request online at:

Re: [Rpm-maint] [rpm-software-management/rpm] Add a rudimentary "make dist" target (61bb33e)

@Conan-Kudo That was my thought too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/commit/61bb33e593c0fa56aaca935da2007fe9bb848fd2#commitcomment-87619137 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Verify that all OpenPGP signatures are a single signature packet (Issue #2233)

Closed #2233 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2233#event-7614349188 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Verify that all OpenPGP signatures are a single signature packet (Issue #2233)

@nwalfield: then there is no bug, closing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2233#issuecomment-1282830219 You are receiving this because you are subscribed to this thread. Message ID:

[Rpm-maint] [rpm-software-management/rpm] Rust-less bootstrapping (Discussion #2234)

Bootstrapping without Rust has been mentioned as a requirement on the Fedora development mailing list. However, not being able to verify signatures is a very bad idea for security. This discussion is about trying to resolve this conundrum. -- Reply to this email directly or view it on

[Rpm-maint] [rpm-software-management/rpm] Verify that all OpenPGP signatures are a single signature packet (Issue #2233)

This is enforced by the current in-tree parser, but (presumably) not by the Sequoia parser. It does not require parsing the contents at all, merely the framing. I am willing to make a patch. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] 4.18.0 unbuildable on macOS (Issue #2222)

`/dev/fd/` is a pretty general workaround, if it works at all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/#issuecomment-1278437471 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] 4.18.0 unbuildable on macOS (Issue #2222)

Could `mkfifoat()` be emulated with `mknodat()` or `/dev/fd/`? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/#issuecomment-1275499958 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Examine Compressed Headers (Issue #2220)

> While the payload is compressed the header is not. This is wasting time and > IO whenever a header is loaded - be it form a package or the RPM BD. > > For the v6 format we need to examine if compressing the headers yields enough > benefits to justify this change. Compressing the main header

Re: [Rpm-maint] [rpm-software-management/rpm] How can I find details on the binary representation of the RPM DB? (Discussion #2211)

> The details of the database format are OFF-LIMITS TO EXTERNAL USERS! > > Sqlite is but one of the possible database formats. If you want to access the > rpm database, you do so through the librpm API. Just because one should not access the rpmdb without going through librpm does not mean

[Rpm-maint] [rpm-software-management/rpm] RPMv6 proposal: treat IMA and fsverity signatures as part of the package (Issue #2200)

In RPMv4, IMA and fsverity signatures are not considered part of the package, but of the signature. Therefore, they are included in the signature header (not the main header), which leads to various problems and increases attack surface. For RPMv6, I propose that they be considered part of

Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import "fails with key 1 import failed" (Discussion #2186)

@sshedi: I suggest taking all of my merged PRs to the OpenPGP code. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2186#discussioncomment-3680832 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] [RFE] Make RPM transaction more robust (Discussion #2193)

One option for Linux would be to apply the changes to an overlayfs, then mount the overlayfs over the root filesystem. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2193#discussioncomment-3680207 You are receiving this because

Re: [Rpm-maint] [rpm-software-management/rpm] Justus/openpgp fixes (PR #1813)

@DemiMarie commented on this pull request. > @@ -503,6 +500,9 @@ static int pgpPrtSubType(const uint8_t *h, size_t hlen, > pgpSigType sigtype, case PGPSUBTYPE_REVOKE_REASON: case PGPSUBTYPE_FEATURES: case PGPSUBTYPE_EMBEDDED_SIG: + pgpPrtHex("", p+1, plen-1);

Re: [Rpm-maint] [rpm-software-management/rpm] Header signatures alone are not sufficient (#1672)

@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:

[Rpm-maint] [rpm-software-management/rpm] Enhance CONTRIBUTING.md (PR #1807)

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 -- *

[Rpm-maint] [rpm-software-management/rpm] Fix link to the kernel coding style (PR #1806)

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 -- *

[Rpm-maint] [rpm-software-management/rpm] Fix typo: “all” not “ll” (PR #1805)

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

Re: [Rpm-maint] [rpm-software-management/rpm] verifySignature(): package signatures must be PGPSIGTYPE_BINARY (PR #1801)

@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

Re: [Rpm-maint] [rpm-software-management/rpm] verifySignature(): package signatures must be PGPSIGTYPE_BINARY (PR #1801)

@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:

Re: [Rpm-maint] [rpm-software-management/rpm] Check that padding is zeroed and regions are consistent (#1613)

@DemiMarie pushed 3 commits. 3a7b40fc54a95ab03ac074f8356bf52a354896ba Check that padding is zeroed and regions are consistent e611b50fe7b97ca2265759e1cce28e23b443211b hdrblobVerifyInfo(): reject trailing junk 0a19ea5c48499940303c134b55d23d9ef8aa9a64 Add assertion to catch an internal error

Re: [Rpm-maint] [rpm-software-management/rpm] verifySignature(): package signatures must be PGPSIGTYPE_BINARY (PR #1801)

@DemiMarie pushed 1 commit. f4521694942624460c7238eb7e61a52f290e35cc verifySignature(): package signatures must be PGPSIGTYPE_BINARY -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] verifySignature(): package signatures must be PGPSIGTYPE_BINARY (PR #1801)

RPM packages are binary documents and must be signed as such. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1801 -- Commit Summary -- *

Re: [Rpm-maint] [rpm-software-management/rpm] Validate and require subkey binding signatures on PGP public keys (#1795)

@DemiMarie requested changes on this pull request. > + if (sigalg->setmpi(sigalg, i, p)) + break; @pmatilai good point. In fact, I would argue that *not* adding the check would make this PR a regression security wise. Would it be possible to include #1705 in this PR? It is

Re: [Rpm-maint] [rpm-software-management/rpm] Validate and require subkey binding signatures on PGP public keys (#1795)

@DemiMarie commented on this pull request. > + if (sigalg->setmpi(sigalg, i, p)) + break; What if I made a good quality PR that fixed the problem, either directly or on to your branch? #1705 got NAK’d on the grounds that it added “another struct pgpDigParams direct access when

Re: [Rpm-maint] [rpm-software-management/rpm] Validate and require subkey binding signatures on PGP public keys (#1795)

@DemiMarie commented on this pull request. > + if (sigalg->setmpi(sigalg, i, p)) + break; > The signature type information is there to tell the reader how to hash the > material for correct results. We ignore the byte _anyhow_ for the package > hashing purposes because it's

Re: [Rpm-maint] [rpm-software-management/rpm] Validate and require subkey binding signatures on PGP public keys (#1795)

@DemiMarie requested changes on this pull request. This needs #1705 or equivalent to ensure that non-`PGPSIGTYPE_BINARY` signatures are not accepted as package signatures. > + if (sigalg->setmpi(sigalg, i, p)) + break; This requires a corresponding change in the package signature

Re: [Rpm-maint] [rpm-software-management/rpm] Validate self-signatures and require subkey bindings on PGP public keys (#1788)

@DemiMarie requested changes on this pull request. Package signatures need to be checked to be of `PGPSIGTYPE_BINARY`, and keys with third-party certifications must not be rejected. I believe nonsensical signature types should be rejected. > + /* ignore unknown types */ + rc = 0;

Re: [Rpm-maint] [rpm-software-management/rpm] Rpm spits informative garbage to stdout instead of stderr (#962)

> Exit code sanity come to mind as a related thing. Does that include exiting with a non-zero status if an I/O error occurs? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Validate self-signatures and require subkey bindings on PGP public keys (#1788)

@DemiMarie requested changes on this pull request. At a minimum, there needs to be a check for signature type in the code that verifies package signatures, now that such signatures will no longer be automatically rejected. > +return rc; +} + +static int pgpVerifySelf(pgpDigParams key,

Re: [Rpm-maint] [rpm-software-management/rpm] [regression?] rpm 4.17 can't find group declared inside sceleton package (#1789)

> Commit > [f9c7b53](https://github.com/rpm-software-management/rpm/commit/f9c7b53f50adc129baee809692d4c80b3bd15432) > is supposed to be a no-op, so if that is the thing changing behavior then we > need to look at it, I don't remember any intentional change to this effect > anyway. That

Re: [Rpm-maint] [rpm-software-management/rpm] brp-strip fails with Guile objects on Fedora 35 (#1765)

> These changes do both to be on the save side. > > On the longer term the question is if the Guile object really should not be > stripped. `eu-strip` should be able to strip those, too. Not sure if we want > to switch over to that in general. Guile is often used as a REPL, so I am not sure if

Re: [Rpm-maint] [rpm-software-management/rpm] Properly quote %sources and %patches (#1781)

> See #1783 (sorry, this was way more fun than what I'm supposed to be doing...) what is that? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Add %{shescape:...} macro for single quoting with escapes for the shell (#1783)

@DemiMarie commented on this pull request. > @@ -1145,6 +1145,29 @@ static size_t doVerbose(MacroBuf mb, rpmMacroEntry me, > ARGV_t argv) return 0; } +static size_t doShescape(MacroBuf mb, rpmMacroEntry me, ARGV_t argv) +{ +char *result, *dst; +const char *src = argv[1]; + +

Re: [Rpm-maint] [rpm-software-management/rpm] Properly quote %sources and %patches (#1781)

@DemiMarie commented on this pull request. > + print("'"..string.gsub(p, "'", "'''").."'".." ") end} +%sources %{lua: for i, s in ipairs(sources) do \ + print("'"..string.gsub(s, "'", "'''").."'".." ") end} ```suggestion print("'"..string.gsub(p, "'", "'''").."' ") end}

Re: [Rpm-maint] [rpm-software-management/rpm] Fix out-of-bounds read parsing old-format packets (#1711)

Rebased on master and added a regression test. -- 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/1711#issuecomment-922374155___

Re: [Rpm-maint] [rpm-software-management/rpm] brp-strip fails with Guile objects on Fedora 35 (#1765)

> ``` > $ file /sbin/ldconfig > /sbin/ldconfig: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), > static-pie linked, BuildID[sha1]=e524d23506ba0c75de1d253087146164328b13b8, > for GNU/Linux 3.2.0, stripped > $ file /bin/file > /bin/file: ELF 64-bit LSB pie executable, x86-64,

Re: [Rpm-maint] [rpm-software-management/rpm] rpm query directory performance (#1770)

> Are there any known workarounds for rpm 4.11.3 (as it's a system version so > I'm stuck with it in the office)? > Maybe there is a patch that could be applied to 4.11.3 without a full upgrade > (so I could convince our admins to apply it)? RPM 4.11.3 is horribly insecure, so unless you are

Re: [Rpm-maint] [rpm-software-management/rpm] brp-strip fails with Guile objects on Fedora 35 (#1765)

Seems like `*.go` files should never be stripped. `*.go` can also be Go source code, and that can’t be stripped either. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] Bail out if a key ID cannot be obtained (#1750)

If a key ID cannot be obtained, the key is useless. This also ensures that pgpPrtKey only needs to handle input that getKeyID has already validated. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1750 -- Commit Summary --

Re: [Rpm-maint] [rpm-software-management/rpm] Check that padding is zeroed and regions are consistent (#1613)

@DemiMarie pushed 1 commit. dff5ec67f5dfd7c4f9989c9b751e6a9c480db817 Add assertion to catch an internal error -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Check that padding is zeroed and regions are consistent (#1613)

@DemiMarie pushed 2 commits. 68a9e05e6ac73b634c81cba72f88d2c992b35e20 Check that padding is zeroed and regions are consistent 36a8ff75e8fc1fc6a85470c5e64748cc118a3e43 hdrblobVerifyInfo(): reject trailing junk -- You are receiving this because you are subscribed to this thread. View it on

[Rpm-maint] [rpm-software-management/rpm] Improve CONTRIBUTING.md and add SECURITY.md (#1747)

More work can obviously be done, but this is a start. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1747 -- Commit Summary -- * Improve CONTRIBUTING.md and add SECURITY.md -- File Changes -- M CONTRIBUTING.md (52)

Re: [Rpm-maint] [rpm-software-management/rpm] Fix out-of-bounds read parsing old-format packets (#1711)

@pmatilai @ffesti ping -- 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/1711#issuecomment-893208394___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Fix out-of-bounds read parsing old-format packets (#1711)

Reopened #1711. -- 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/1711#event-5115514230___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Clean up curve ID handling (#1725)

@DemiMarie pushed 1 commit. cd2be7b7069601138869e409c612e506510d77cd Clean up curve ID handling -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Fingerprint subpacket parsing support (#1728)

@DemiMarie pushed 1 commit. 935d416a91f121010d5034d0df820c48ad6c0fba v5 fingerprint parsing support -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Fingerprint subpacket parsing support (#1728)

> Oops, that's an expired version. The current one is: > > https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-03.txt Right now, we don’t support v5 keys at all. Adding support for v5 fingerprints when we do not support v5 keys would be rather inconsistent. -- You are receiving

Re: [Rpm-maint] [rpm-software-management/rpm] Improve the OpenSSL crypto backend (#1610)

@ffesti ping -- 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/1610#issuecomment-874242576___ Rpm-maint mailing list

  1   2   3   4   5   >