More or less. It wouldn't hurt to add a small blurb to INSTALL explaining the
new --with-crypto option plus a disclaimer about the openssl license issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The attached file causes an out of bounds read in pgpPrtSig. This is a
different bug from #149, although it's in the same function.
[oob-heap-pgpPrtSig-rpmpgp-633.zip](https://github.com/rpm-software-management/rpm/files/762089/oob-heap-pgpPrtSig-rpmpgp-633.zip)
Here's the asan output:
```
@pmatilai @ffesti OK, so is this good to merge at this point?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@t8m Just to confirm, does the current version correctly address your concerns
about overwriting the BIGNUM values?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
t8m approved this pull request.
This looks good and it simplifies the patch, there is no point in using OpenSSL
allocators for memory that is not later freed inside OpenSSL.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@fweimer I see, that makes much more sense.
--
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/144#issuecomment-278350760___
Conan-Kudo requested changes on this pull request.
I'd prefer that the new extra scripts be disabled by default for now, rather
than enabled by default.
In addition, instead of using `dont_`, I'd suggest using `enable_` or
`disable_` and wording it appropriately. That's consistent with other
@Conan-Kudo:
> Wouldn't that happen during the package build, rather than at runtime? It
> seems like that's a package build-time action.
I quoted the wrong part (Github doesn't seem to support automated quoting). I
was actually referring to this:
> I was thinking that it would be better to do
Thanks, but you made me realize one problematic thing with that patch: it was
now a situation where on OpenSSL 1.0.2, we are allocating with `malloc()` and
freeing with `OPENSSL_free()`, which is not correctly paired. We really need to
be doing one or the other, and it looks to me like there
Oh and thanks for the patch!
--
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/146#issuecomment-278339686___
Rpm-maint mailing
Just FWIW, my previous comment was written before seeing your latest fixup, so
it was more about general principle than the actual fixup. Didn't expect you to
fix it that fast :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Hmm, well I was trying to remain consistent, but you may be right; the places
where I'm using `OPENSSL_zalloc()` would all be happily satisfied by using
regular malloc or the RPM allocators, so I think I'll just rework the patches
to use those instead.
Also, I noted yesterday that the long
Mmh, I'd rather not have hundreds of lines of additional configure goo just to
check for incompatibilities between a couple of versions of an optional crypto
backend, lets try to keep the checks in check, so to speak.
But if OPENSSL_malloc() and OPENSSL_free() are not compatible with common
@sgallagher pushed 1 commit.
f59f329 fixup! Add initial OpenSSL support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Actually, that warning isn't harmless. I need to add a configure check for that.
It's strange, neither `OPENSSL_malloc()` nor `OPENSSL_free()` are listed in the
official 1.0.2 [docs](https://www.openssl.org/docs/man1.0.2/crypto/). That's
why I created their compatibility functions. I need to be
Yup. It's in one of those > 100 macro expansions within rpm which have no way
of returning an error, eg rpmExpand() has no way of indicating an error as it
is, and there's no other API that it can be directly replaced with in all cases.
Which is not to say it shouldn't be fixed but it's far
@ffesti I restructured the code to get rid of the ugly 'static' globals.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
mlschroe commented on this pull request.
> +switch (num) {
+case 0:
+if (!bn) {
+bn = sig->bn = BN_new();
+}
+if (!bn) return 1;
+
+/* Create a BIGNUM from the signature pointer.
+ Note: this assumes big-endian data as required
+
Right, since rpm >= 4.13 the expectation is to have gpg-agent handle this.
Distros have been patching rpm to use gpg2 but as of 4.13 upstream still
defaults to gpg1 so I guess this is the behavior you get with real upstream
defaults. Dangers of distro patches...
As a workaround you should be
Merged #146.
--
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/146#event-953501576___
Rpm-maint mailing list
pmatilai approved this pull request.
As per
https://selinuxproject.org/page/NB_Imp_SELinux-aware_Apps#Implementing_SELinux-aware_Applications_2,
one should check the string_to_security_class() return value for errors, but
then I guess it's not that important for a hardcoded, known value such
Because of `makeGPGSignature()` being called separately for header and contents
([sign/rpmgensig.c:403](https://github.com/rpm-software-management/rpm/blob/master/sign/rpmgensig.c#L403)),
and that GPG asks for password itself — each time it is called — signing every
single rpm requires typing
Right, padding seems to be working now too and not seeing anything weird in
brief testing (throw a big pile of both good and fuzzed packages at it,
testsuite passes).
I'm getting this (apparently harmless) warning on F25 (so openssl-1.0.2j):
```
digest_openssl.c:26:0: warning: "OPENSSL_free"
23 matches
Mail list logo
