pmatilai 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
+
pmatilai 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
+
@bmwiedemann wrote:
> The alternative approach would be to change the macro generating them and
> first touch source .py files to set their date to $SOURCE_DATE_EPOCH so that
> this gets embedded in .pyc headers
I doubt that RPM can do this without delayed script execution because the
The attached file will cause an oud of bounds heap read in "rpmkeys -K".
[rpmkeys-pgpPrtSubType-rpmpgp-444.zip](https://github.com/rpm-software-management/rpm/files/755884/rpmkeys-pgpPrtSubType-rpmpgp-444.zip)
Here's the address sanitizer output:
```
==15315==ERROR: AddressSanitizer:
sgallagher 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
+
sgallagher commented on this pull request.
> +EVP_PKEY_free(key->evp_pkey);
+key->evp_pkey = NULL;
+RSA_free(rsa);
+}
+
+return 1;
+}
+
+static int pgpSetKeyMpiRSA(pgpDigAlg pgpkey, int num, const uint8_t *p)
+{
+size_t mlen = pgpMpiLen(p) - 2;
+struct
sgallagher commented on this pull request.
> +int DSA_SIG_set0(DSA_SIG *sig, BIGNUM *r, BIGNUM *s)
+{
+if (!sig) return 0;
+
+if (r) {
+sig->r = r;
+}
+
+if (s) {
+sig->s = s;
+}
+
+return 1;
+}
+#endif /* HAVE_DSA_SIG_SET0 */
+
I'm not really sure what
t8m commented on this pull request.
> +int DSA_SIG_set0(DSA_SIG *sig, BIGNUM *r, BIGNUM *s)
+{
+if (!sig) return 0;
+
+if (r) {
+sig->r = r;
+}
+
+if (s) {
+sig->s = s;
+}
+
+return 1;
+}
+#endif /* HAVE_DSA_SIG_SET0 */
+
In above functions you do not
@t8m Sorry, could you be more specific? I'm not sure which functions are risky
or which references need to be freed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
t8m requested changes on this pull request.
The various _set0_ functions you add for compatibility with OpenSSL 1.0.2 do
not properly handle multiple calls of the same function on the object - the old
references are not freed. I understand that in the current patch this probably
isn't a
@Conan-Kudo I just pushed a couple additional configure.ac changes that should
ensure that it's using at least OpenSSL 1.0
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@sgallagher pushed 2 commits.
de07401 fixup! Add initial OpenSSL support
a7bc1e4 fixup! Add compatibility layer for OpenSSL 1.0.2
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo Thanks, I'll see if I can make the configure checks a little more
strict.
Just to confirm: those other two bullet points were you asserting that things
worked correctly, right? (It's a little confusing when corrective feedback is
in the same list).
--
You are receiving this
Closed #131.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/131#event-950123502___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
Oh. I suppose it even makes sense. Fixed now, by simply giving the Doxyheader
files a .h extension (commit e8438555279b9a4e406ffd0edfc224de1c2862a6).
Thank you for figuring this out!
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
15 matches
Mail list logo
