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 to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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++, which require more CPU and RAM during build, is making it very difficult to natively compile on slow processors. One potential solution would be for RPM to support running the test suite remotely, or at least in a separate step. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2884 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 binaries, then makes a system image from those packages. > You can also pick what package format you prefer: ipk/deb/rpm, or all three. Ah, then there is not a security concern at all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1829376458 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 whole bunch of logic nobody is interested in implementing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1829367779 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 used to compile code for the target system. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1829363803 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 we > don't have control over what versions we're going to get, and how they are > built and configured. To ensure things work in a reproducible manner, yocto > builds its own rpm executable that can run on the build machine. What about fetching a correctly configured binary RPM and verifying its hash before using it? > FWIW, the only host tools allowed to bootstrap the yocto build are python, > gcc, wget, tar, git and various (de)compression utilities - things you need > to fetch the sources, and bootstrap a cross-compiler. Do you also need tools to cryptographically verify the downloaded sources? Or is that done in Python? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1829305689 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 from an image file. Package manager is used to compose that root > filesystem from local packages in a controlled CI environment (where > package-level security isn't needed), and to allow developers to install > additional items into a running system on their desks used for development > and testing (where there's no need to sign packages either). > > 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. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1826442158 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1826160579 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 considered security vulnerabilities in the upstream code, so that they could be handled via the private channels used for such things (secal...@redhat.com in this case). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7511960 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7501644 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 because it would require root privileges to exploit, but in this case the root filesystem itself is untrusted. That’s why I suggested compiling librpm via WebAssembly, so that the impact of a compromise is limited. Without a trick like this, the only other approach that meets certain security requirements is to create a new virtual machine for each and every container being scanned, which is slow, uses lots of memory, and is incompatible with most cloud environments. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7491327 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 security concerns. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-7482856 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1652024246 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 single tag data entry in the main header, with each hash being taken over a 1 mebibyte chunk of the payload. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2416#issuecomment-1597752331 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 bugs that almost certainly won’t be
fixed. To give just one example, revocation handling is not implemented at all.
> Or will an external implementation ("rpm-sequouia" backend) be required in
> future versions (e.g. next Fedora)?
It’s already the default in Fedora 38.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1553680881
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2503#issuecomment-1536435351 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-1510444939 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 it on GitHub: https://github.com/rpm-software-management/rpm/pull/2434#pullrequestreview-1344522699 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 reported back in 2022, and should not increase the maintenance burden significantly. It also ensures consistency with the Sequoia implementation, which has a much stricter parser than GnuPG has. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1462566447 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 padding is ignored by `hdrblobImport()`. That said, the current solution is simpler and _much_ more obvious from the perspective of package reading. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5090054 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-5054477 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ 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 %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.
```
> +-c create the build directory (and change to it) before unpacking
+-D do not delete the build directory prior to unpacking (used
+when more than one source is to be unpacked with `-a` or `-b`)
+-n DIR set the name of build directory (default is `%{name}-%{version}`)
+-T skip the default unpacking of the first source (used with
+`-a` or `-b`)
+-q operate quietly
+```
+
+ %patch
+
+`%patch [options] [arguments]`
+
+`%patch` is used to apply patches on top of the just unpacked pristine sources.
+Historically it supports multiple strange syntaxes which are nowadays
+deprecated. To apply patch number 1, the main syntaxes are:
I’m curious what the others are :smile:.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2352#pullrequestreview-1250541133
You are receiving this because you are subscribed to this thread.
Message ID: ___
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: 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: ___ 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: 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. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 > really belong there in the first place. In macros I agree, but in scriplets one might well want to be able to e.g. edit complex file formats. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1353459293 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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
+ID="$(cat /etc/system-release)"
+fi
+printf '%s' "${ID}"
+}
+
+RPM_BUILD_ROOT="$1"
+RPM_BUILD_DIR="$2"
A separate buildinfo RPM seems like the best option to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1532#discussion_r1032852444
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/issues/2127#issuecomment-1320964390 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 > ``` Sorry about that. Without the fix the internal backend segfaults IIRC. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2272#issuecomment-1309446364 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2242/files/e0c93993fe673f6bc8103fc87a4e2c6f3f5c38f9..d9f6fcb91fdb82b07afdaf1b6e82533755f627c3 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2249#issuecomment-1296733767 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2242/files/8ba0903e01c1515b992c2306b360c7f1384a5272..e0c93993fe673f6bc8103fc87a4e2c6f3f5c38f9 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2219#issuecomment-1291556871 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/commit/61bb33e593c0fa56aaca935da2007fe9bb848fd2#commitcomment-87760524 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 2fc57f6cc3cb4dc8b66054744ff09b57a3897597 Restrict packets following a subkey 514eaea91fb600674ed4b2fdc0f99754d91f7d8d Ignore revoked subkeys f308050a84e270c1f02451160d16dbecb374752b Mark signatures by revoked keys as untrusted 4088faf58a9540f6a96042054f33cdb6a07e5132 Handle some critical subpackets -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1993/files/8809f669c4f096f71ec6760da953927aa35d1ee7..4088faf58a9540f6a96042054f33cdb6a07e5132 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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: https://github.com/rpm-software-management/rpm/pull/2242 -- Commit Summary -- * Avoid type confusion when verifying signatures * Check packet types of signatures and public keys * Reject multiple PGPTAG_PUBLIC_KEY packets -- File Changes -- M rpmio/rpmpgp_internal.c (33) A tests/data/keys/type-confusion.asc (29) M tests/rpmsigdig.at (12) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2242.patch https://github.com/rpm-software-management/rpm/pull/2242.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2242 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 GitHub: https://github.com/rpm-software-management/rpm/discussions/2234 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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: https://github.com/rpm-software-management/rpm/issues/2233 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 is okay, as it is signed. Compressing the signature header is a bad idea unless an extra signature is added after compression. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2220#issuecomment-1268793749 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 that one might not be curious about the actual rpmdb format. I know I am! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2211#discussioncomment-3788032 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 the package itself, and so included in the main header. Adding IMA and fsverity signatures to a package would thus create a new package. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2200 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: ___ 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] 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 you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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);
+ break;
+ case PGPSUBTYPE_NOTATION:
PGPSUBTYPE_NOTATION is definitely not recognized unless the notation name is
recognized.
--
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/1813#discussion_r737527899___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/1672/files/996644d28592e1f88d0dfadd46e4fa3ef275186d..0bd36c11c2e5d9ec1a9f79a30db29ba909cf6e7e ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 -- * https://github.com/rpm-software-management/rpm/pull/1807/commits/8e927b8afed4ce9488b5fe5172031fa0ef8c3b58;>Document that using assert() is frowned upon -- File Changes -- M CONTRIBUTING.md (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1807.patch https://github.com/rpm-software-management/rpm/pull/1807.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/1807 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 -- * https://github.com/rpm-software-management/rpm/pull/1806/commits/db87080edc31baece1a17fe818e477e93256da64;>Fix link to the kernel coding style -- File Changes -- M CONTRIBUTING.md (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1806.patch https://github.com/rpm-software-management/rpm/pull/1806.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/1806 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 “ll” -- File Changes -- M CONTRIBUTING.md (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1805.patch https://github.com/rpm-software-management/rpm/pull/1805.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/1805 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 good point I had not considered, thanks. If it is okay with you I
can make a PR to add this to `CONTRIBUTING.md`
> @@ -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;
+if (sinfo->sig && pgpSignatureType(sinfo->sig) == PGPSIGTYPE_BINARY)
Done, 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/1801#pullrequestreview-785916855___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/1801/files/f4521694942624460c7238eb7e61a52f290e35cc..17c93c31eceed4cd9a3e78385756f4804c047f50 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1613/files/dff5ec67f5dfd7c4f9989c9b751e6a9c480db817..0a19ea5c48499940303c134b55d23d9ef8aa9a64 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/1801/files/9069a4cd36597badd292bf5c6aac3f3ed89e0c73..f4521694942624460c7238eb7e61a52f290e35cc ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 -- * https://github.com/rpm-software-management/rpm/pull/1801/commits/9069a4cd36597badd292bf5c6aac3f3ed89e0c73;>verifySignature(): package signatures must be PGPSIGTYPE_BINARY -- File Changes -- M lib/rpmvs.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1801.patch https://github.com/rpm-software-management/rpm/pull/1801.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/1801 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 tiny and passes the regression test suite, and can be replaced with a better solution later. -- 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/1795#pullrequestreview-782356055___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 we're trying to eliminate those.” I can instead add a proper accessor function (is pgpDigParamsSigType okay?) and use it. > Silly, because if you get an admin to import a key file you have access to, > you don't need to pull off stunts like fiddle with subkey binding signatures. The main worry is if someone does something like: ``` $ gpg --export 'some trusted fingerprint' ``` and their `/usr/bin/gpg` doesn’t bother to check subkey binding signatures when exporting. -- 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/1795#discussion_r729033785___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 just not that intersting for our purposes. It also provides cryptographic domain separation between different types of signatures, which prevents a signature of a public key, a certification signature, or a revocation signature from being accepted as a signature of a document. That is where the security aspect comes from. In the case of RPM, this is somewhat mitigated since the data being signed must start with 0x8e, which means it cannot collide data being signed in any of the other standardized signature types. > A better implementation would do things differently in many ways, but > removing that misplaced semi-random check from 20 years ago is hardly a > security regression. See above: in the case of RPM it may not be exploitable, but it could become exploitable if future changes are made to the OpenPGP standard. Best to add the check now as a precaution. -- 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/1795#discussion_r728970189___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 checking code to ensure that package signatures are `PGPSIGTYPE_BINARY`. #1705 is one implementation, and I can replace it with a better one that uses proper accessor functions. > + 0x99, + (pkt->blen >> 8), + (pkt->blen ), This is inconsistent (at best) for keys larger than 0x bytes. Not sure if such keys should just be rejected. -- 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/1795#pullrequestreview-778605073___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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;
```suggestion
/* reject unknown types */
```
> + if (sigalg->setmpi(sigalg, i, p))
+ break;
A certification or binding signature isn’t a valid package signature and should
not be accepted where a package signature is required. The parser doesn’t
currently know what kind of signature is expected and so can’t make that
decision. That said, another option would be to add a new API function that
only parses signatures, and which expects the type of the signature as an
argument.
> + 0xb4,
+ (pkt->blen >> 24),
+ (pkt->blen >> 16),
+ (pkt->blen >> 8),
+ (pkt->blen ),
+ };
+ rpmDigestUpdate(hash, head, 5);
+ rpmDigestUpdate(hash, pkt->body, pkt->blen);
+ rc = 0;
+}
+return rc;
+}
+
+static int pgpVerifySelf(pgpDigParams key, pgpDigParams selfsig,
+ const struct pgpPkt *all, int i)
+{
Edited
--
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/1788#pullrequestreview-777427981___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/issues/962#issuecomment-940081938___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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, pgpDigParams selfsig,
+ const struct pgpPkt *all, int i)
+{
+int rc = -1;
+DIGEST_CTX hash = NULL;
+
+switch (selfsig->sigtype) {
+case PGPSIGTYPE_SUBKEY_BINDING:
+ hash = rpmDigestInit(selfsig->hash_algo, 0);
+ if (hash) {
+ rc = hashKey(hash, [0], PGPTAG_PUBLIC_KEY);
+ if (!rc)
+ rc = hashKey(hash, [i-1], PGPTAG_PUBLIC_SUBKEY);
Presumably `i` must always be at least 1 here. If so, then I would add an
assertion and a comment explaining why that is the case.
> + hash = rpmDigestInit(selfsig->hash_algo, 0);
+ if (hash) {
+ rc = hashKey(hash, [0], PGPTAG_PUBLIC_KEY);
+ if (!rc)
+ rc = hashKey(hash, [i-1], PGPTAG_PUBLIC_SUBKEY);
+ }
+ break;
+case PGPSIGTYPE_GENERIC_CERT:
+case PGPSIGTYPE_PERSONA_CERT:
+case PGPSIGTYPE_CASUAL_CERT:
+case PGPSIGTYPE_POSITIVE_CERT:
+ hash = rpmDigestInit(selfsig->hash_algo, 0);
+ if (hash) {
+ rc = hashKey(hash, [0], PGPTAG_PUBLIC_KEY);
+ if (!rc)
+ rc = hashUser(hash, [i-1], PGPTAG_USER_ID);
Same as above.
> +if (pkt->tag == exptag) {
+ uint8_t head[] = {
+ 0x99,
+ (pkt->blen >> 8),
+ (pkt->blen ),
```suggestion
if (pkt->tag == exptag && pkt->blen <= 0x) {
uint8_t head[] = {
0x99,
(pkt->blen >> 8),
(pkt->blen ),
```
If `pkt->blen` is greater than 0x the formula provided by the OpenPGP
specification for hashing a key makes no sense.
> + }
+ break;
+case PGPSIGTYPE_GENERIC_CERT:
+case PGPSIGTYPE_PERSONA_CERT:
+case PGPSIGTYPE_CASUAL_CERT:
+case PGPSIGTYPE_POSITIVE_CERT:
+ hash = rpmDigestInit(selfsig->hash_algo, 0);
+ if (hash) {
+ rc = hashKey(hash, [0], PGPTAG_PUBLIC_KEY);
+ if (!rc)
+ rc = hashUser(hash, [i-1], PGPTAG_USER_ID);
+ }
+ break;
+default:
+ /* ignore unknown types */
+ rc = 0;
I am 99% certain this should be an error condition; such signatures make no
sense.
> + if (sigalg->setmpi(sigalg, i, p))
+ break;
With this change, RPM needs to check that package signatures are in fact
signatures of binary documents. I am not aware of an actual exploit, but it is
the Right Thing To Do, since a security patch should not regress security
elsewhere.
> if (pkttype == PGPTAG_SIGNATURE)
break;
+
+ if (alloced <= i) {
+ alloced *= 2;
```suggestion
if (alloced > INT_MAX / 2 || alloced > SIZE_MAX / (4 *
sizeof(*all)))
abort();
alloced *= 2;
```
This is a last-ditch check against memory corruption due to integer overflow.
Such long keys should be rejected earlier in any case.
> + 0xb4,
+ (pkt->blen >> 24),
+ (pkt->blen >> 16),
+ (pkt->blen >> 8),
+ (pkt->blen ),
+ };
+ rpmDigestUpdate(hash, head, 5);
+ rpmDigestUpdate(hash, pkt->body, pkt->blen);
+ rc = 0;
+}
+return rc;
+}
+
+static int pgpVerifySelf(pgpDigParams key, pgpDigParams selfsig,
+ const struct pgpPkt *all, int i)
+{
```suggestion
{
// The only caller of pgpVerifySelf always passes a number
// greater than 0
assert(i > 0 && "pgpVerifySelf passed invalid i");
```
> }
}
- if (pgpPrtPkt(, digp))
+ if (digp->tag == PGPTAG_PUBLIC_KEY && pkt->tag == PGPTAG_SIGNATURE)
+ selfsig = pgpDigParamsNew(pkt->tag);
I am fine with assuming and requiring that the self-signature comes first,
provided that doing so is interoperable. Keys with non-self-signatures
obviously need to be accepted, but I am fine with RPM ignoring the extra
signatures and omitting them from the parsed result.
> break;
+ if (pkt->tag == PGPTAG_PUBLIC_SUBKEY)
+ expect = PGPTAG_SIGNATURE;
I believe GPG ignores User ID packets that have no self-signatures. RPM should
either reject such packets or ignore them; processing them as if they were
verified is a bad idea.
--
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/1788#pullrequestreview-776261179___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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 doesn't change the fact that rpm cannot bootstrap user/group > info, never could. What is the “correct” way to do this? Explicit chown in a postinst script? -- 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/1789#issuecomment-932240219___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 this is a good idea. -- 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/1765#issuecomment-929055972___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/1781#issuecomment-925678230___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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];
+
+result = dst = xmalloc(strlen(src) * 4 + 3);
Are we sure this won’t integer overflow?
--
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/1783#pullrequestreview-761397163___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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}
%sources %{lua: for i, s in ipairs(sources) do \
print("'"..string.gsub(s, "'", "'''").."' ") end}
```
--
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/1781#pullrequestreview-760060877___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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, version 1 (SYSV), > dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=a32704f3e43df7519c65f06adf61d4d9bdc549bf, for GNU/Linux 3.2.0, > stripped > $ file /bin/gcc > /bin/gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically > linked, interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=e3a77ec7634d2b4b939b7fb62d7bcdd3860f17bf, for GNU/Linux 3.2.0, > stripped > $ file /usr/lib64/guile/2.2/ccache/ice-9/readline.go > /usr/lib64/guile/2.2/ccache/ice-9/readline.go: ELF 64-bit LSB shared object, > no machine, version 1 (embedded), dynamically linked, with debug_info, not > stripped > ``` > > Is the string `no machine` good enough for detecting Guile objects? Not sure. I would prefer just skipping `*.go` files entirely. -- 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/1765#issuecomment-922366738___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 using `repo_gpgcheck=1` on all of your repositories you have bigger problems. -- 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/1770#issuecomment-912684405___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/issues/1765#issuecomment-907579133___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 -- * Bail out if a key ID cannot be obtained -- File Changes -- M rpmio/rpmpgp.c (20) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1750.patch https://github.com/rpm-software-management/rpm/pull/1750.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/1750 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/1613/files/36a8ff75e8fc1fc6a85470c5e64748cc118a3e43..dff5ec67f5dfd7c4f9989c9b751e6a9c480db817 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 GitHub: https://github.com/rpm-software-management/rpm/pull/1613/files/e4a50359d067f7b773d2126851d1fc6c87a61670..36a8ff75e8fc1fc6a85470c5e64748cc118a3e43 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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) A SECURITY.md (25) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1747.patch https://github.com/rpm-software-management/rpm/pull/1747.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/1747 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/1725/files/8bcd9fea351eac8e0fe7ec1c7bd547fa1032f512..cd2be7b7069601138869e409c612e506510d77cd ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/1728/files/388bfee690b0cf54f7f3f01d11412c6f19ae476c..935d416a91f121010d5034d0df820c48ad6c0fba ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 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/1728#issuecomment-885302741___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Avoid undefined shifts (#1547)
@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/1547#issuecomment-874223347___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Header signatures alone are not sufficient (#1672)
@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/1672#issuecomment-874223443___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
