Speaking with my [CBL-Mariner](https://github.com/microsoft/CBL-Mariner) distro
maintainer hat on- no objections to having a floor of cmake 3.20. The lowest
version of cmake we support in Mariner at this time is 3.21.4.
--
Reply to this email directly or view it on GitHub:
@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
I've got it to the point of building with `make`, but `make check` has a lot of
failures.
`build.sh`
```
#!/bin/bash
set -ex
yum install -y \
audit-libs-devel \
autoconf \
automake \
bzip2 \
cmake \
dbus-devel \
doxygen \
elfutils-devel \
file-devel \
file-libs \
gcc \
> The existence of .sqlite-shm is required for read-only WAL mode to work at
> all (a very important use-case being queries by regular users), see
> https://www.sqlite.org/wal.html#read_only_database
I find this weird - because unprivileged code can't write directly to the
database, what
Hmm, so the SPECPARTS directory (whether its empty or not at the end of
%install) could be used for determining whether the feature was used during a
build, so it could be recorded as an rpmlib() dependnecy on src.rpm files
similar to DynamicBuildRequires. If we want to - we obviously do not
> Well, the sub directory is mainly there so placing specparts on older
> rpmbuild versions will fail and they won't just be silently ignored.
Yup, I got that.
> What about SPECPARTS as dir name.
It's loud, but at least it's to the point. Add a %_specpartsdir macro, point it
to that and we
Heh, a rare genuine vintage dupe. Who knows, may even be worth something
:smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2243#issuecomment-1291901310
You are receiving this because you are subscribed to this thread.
Message ID:
> > The patch now uses a SPECS sub dir in the buildsubdir
>
> Names are hard, but this directory is nothing at all like SPECS in
> %{_topdir}, I don't think it should share that name. SPEC, maybe. Except, I
> think we may want to use such a directory for other purposes too, which is
> why the
As for the directory name: add a macro for it, and document *that* instead of
the hardcoded value. Otherwise, two weeks from the release of 4.19 we'll have a
ticket requesting for one. Been there. Also that gives us at least a fleeting
chance to rename it should such a thing be needed someday,
On the positive side, spec parse with and without this produce identical
results on texlive.spec and kernel.spec (both fairly complicated beasts),
except for the expected mkdir on the SPECS dir.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> +# Check if dynamic spec generation works
+AT_SETUP([rpmbuild with dynamic spec generation])
+AT_KEYWORDS([build])
+RPMDB_INIT
+AT_CHECK([
+
+run rpmbuild --noclean\
+ -ba "${abs_srcdir}"/data/SPECS/dynamic.spec
+],
+[0],
+[ignore],
+[ignore])
+
@pmatilai commented on this pull request.
> @@ -2272,3 +2272,27 @@ runroot rpmbuild \
],
[ignore])
AT_CLEANUP
+
+# --
+# Check if dynamic spec generation works
+AT_SETUP([rpmbuild with dynamic spec generation])
+AT_KEYWORDS([build])
+RPMDB_INIT
+AT_CHECK([
+
+run
> The patch now uses a SPECS sub dir in the buildsubdir
Names are hard, but this directory is nothing at all like SPECS in %{_topdir},
I don't think it should use this name. SPEC, maybe. Except, I think we may want
to use such a directory for other purposes too, which is why the spec snippets
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:
As we're moving to cmake in the next major release, here's a bit of a community
poll: what would be a reasonable minimum version to require?
Rpm is conservative in its requirements so it's not like we'd require a cmake
from last week or even last year, but AIUI cmake is very different from
Readability/style issues aside, yes we need to care about fixing segfaults as
long as the internal parser is there. Which might be a while. Thanks for
looking into this!
Here again though, it's really the subkey stuff that is even more brittle. As
the Sequoia option is now in, we could now
@pmatilai commented on this pull request.
> pgpDigAlg sa = sig->alg;
pgpDigAlg ka = key->alg;
- if (sa && sa->verify) {
+ if (sa && sa->verify &&
+ sig->pubkey_algo == key->pubkey_algo) {
Another broken indentation here. A (continued) conditional on the same
@pmatilai commented on this pull request.
> @@ -1150,9 +1153,13 @@ rpmRC pgpVerifySignature(pgpDigParams key,
> pgpDigParams sig, DIGEST_CTX hashctx)
* done all we can, return NOKEY to indicate "looks okay but dunno."
*/
if (key && key->alg) {
+ if (key->tag !=
@pmatilai commented on this pull request.
> @@ -1124,6 +1124,9 @@ rpmRC pgpVerifySignature(pgpDigParams key, pgpDigParams
> sig, DIGEST_CTX hashctx)
if (sig == NULL || ctx == NULL)
goto exit;
+if (sig->tag != PGPTAG_SIGNATURE)
+ goto exit; /* not a signature */
This
@pmatilai commented on this pull request.
> const uint8_t *pend = h + hlen;
int curve = 0;
+if (keyp->tag != PGPTAG_PUBLIC_KEY && keyp->tag != PGPTAG_PUBLIC_SUBKEY)
+ return rc; /* Not a public key */
+if (keyp->alg)
+ return rc; /* We can't handle more than one
@pmatilai commented on this pull request.
> const uint8_t *pend = h + hlen;
int curve = 0;
+if (keyp->tag != PGPTAG_PUBLIC_KEY && keyp->tag != PGPTAG_PUBLIC_SUBKEY)
+ return rc; /* Not a public key */
This isn't in rpm style of commenting: it's stating the obvious, and code
Lua upstream does not provide a pkg-config file, but we rely on one being
present for building rpm. Apparently all relevant distros patch Lua to add that
.pc and using one when present is fine, but we should not *rely* on downstream
patches.
This is the case in both the new cmake build and
> 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
23 matches
Mail list logo
