> In general, I noticed that OpenSSL and LibreSSL don't seem to pay attention
> to the bugs that are fixed in BoringSSL and *ring*. See, for
> example:
We don't have the time to follow other forks, basically.
I don't see that changing.
--
openssl-dev mailing list
To unsubscribe:
Salz, Rich wrote:
>> Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2].
>> Please make sure you consider the impact of those changes on your own
>> projects.
>
> Not sure what you're asking for.
In general, I noticed that OpenSSL and LibreSSL don't seem
> Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2].
> Please make sure you consider the impact of those changes on your own
> projects.
Not sure what you're asking for.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Hi,
Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or
[2]. Please make sure you consider the impact of those changes on your
own projects.
[1] https://boringssl.googlesource.com/boringssl/+log/
[2] https://github.com/briansmith/ring
Cheers,
Brian
--
https://briansmith.org/
The RSA_memory_lock (crypto/rsa/rsa_lib.c) call isn't mentioned in the
documentation. It also isn't called from anywhere inside OpenSSL.
The rsa.h header file says:
| /* This function needs the memory locking malloc callbacks to be installed */
| int RSA_memory_lock(RSA *r);
The
Fixed; see RT 3359 per Steve.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3499
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This API is gone. Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3921
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/359 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3980
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/872 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4432
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/683 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4308
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
fixed some time ago.,
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/466 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4121
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
: https://github.com/openssl/openssl/pull/452 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4108
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/395 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/355 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3986
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/227 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3709
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/215 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3616
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/172 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3533
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
https://github.com/openssl/openssl/pull/139 Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3305
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This duplicates https://github.com/openssl/openssl/pull/258 so closing the
ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2698
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
This was implemented some time ago (not sure who). The nmflag variable is used
in name_print in apps/crl.c Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2894
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
fixed with commit fe2d149 in master. Not backported, code has changed.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2867
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
A quick question about this configuration... Should Linux-x32 enable
ec_nistp_64_gcc_128 by default? Does anything prohibit
ec_nistp_64_gcc_128 in this configuration?
# ./Configure linux-x32
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
no-asan
> ... What one can discuss is to have
> ./config (not ./Configure) detect x32 environment and pass alternative
> config line to ./Configure. That's how it worked so far and I see no
> reason to change it by moving platform detection logic to ./Configure.
--
Ticket here:
>>> # ./config -mx32
>>> Operating system: x86_64-whatever-linux2
>>> Configuring for linux-x86_64
>>>
>>> Perhaps the second case should fail at configure just like the first
>>> case. Upon failure, it would be nice to tell the user what to do:
>>> "Please configure with ./Configure linux-x32"
>>
On Thu, Jun 23, 2016 at 6:18 AM, Jeffrey Walton wrote:
> Here's a couple more ways things don't work as expected:
>
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev
>> # ./config -mx32
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>>
>> Perhaps the second case should fail at configure just like the first
>> case. Upon failure, it would be nice to tell the user what to do:
>> "Please configure with ./Configure linux-x32"
>
> Well,
Hi,
Recently, I found some bugs in ver.1.0.2d.
DESCRIPTION
_
1. Line 122 in a_enum.c: return (0xL);
I think it should be "return -1;".
2. Line 149 in a_enum.c: if (BN_is_negative(bn))
I think it should be "if (BN_is_negative(bn) && !BN_is_zero(bn))".
3. Line 161 and line 164
> Fair enough, agreed.
>
> But Configure ignored my instructions:
>
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg:
On Thu, Jun 23, 2016 at 7:10 AM, Andy Polyakov via RT wrote:
A quick question about this configuration... Should Linux-x32 enable
ec_nistp_64_gcc_128 by default? Does anything prohibit
ec_nistp_64_gcc_128 in this configuration?
# ./Configure linux-x32
>>> A quick question about this configuration... Should Linux-x32 enable
>>> ec_nistp_64_gcc_128 by default? Does anything prohibit
>>> ec_nistp_64_gcc_128 in this configuration?
>>>
>>> # ./Configure linux-x32
>>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>>> no-asan
I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
and working from HEAD:
# git rev-parse HEAD
b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
Running 'make test' under a machine configured with './Configure
linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self
On Thu, Jun 23, 2016 at 6:52 AM, Andy Polyakov via RT wrote:
>> A quick question about this configuration... Should Linux-x32 enable
>> ec_nistp_64_gcc_128 by default? Does anything prohibit
>> ec_nistp_64_gcc_128 in this configuration?
>>
>> # ./Configure linux-x32
>>
> A quick question about this configuration... Should Linux-x32 enable
> ec_nistp_64_gcc_128 by default? Does anything prohibit
> ec_nistp_64_gcc_128 in this configuration?
>
> # ./Configure linux-x32
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> no-asan [default]
On Thu, Jun 23, 2016 at 6:44 AM, Andy Polyakov via RT wrote:
>> you're not allowed to break the compile, regardless of whether there's
>> a proper "X32" kernel.
>
> I don't understand what do you mean by "break the compile". I'd say it's
> the kind of thing that lies on both
On Thu, Jun 23, 2016 at 6:31 AM, Andy Polyakov via RT wrote:
>>> Here's a couple more ways things don't work as expected:
>>>
>>> # ./config CFLAGS="-mx32"
>>> Operating system: x86_64-whatever-linux2
>>> Configuring for linux-x86_64
>>> Configuring OpenSSL version
> you're not allowed to break the compile, regardless of whether there's
> a proper "X32" kernel.
I don't understand what do you mean by "break the compile". I'd say it's
the kind of thing that lies on both parties. We are responsible for
providing code and config lines, but you have
On Thu, Jun 23, 2016 at 6:25 AM, Andy Polyakov via RT wrote:
>> Here's a couple more ways things don't work as expected:
>>
>> # ./config CFLAGS="-mx32"
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> Configuring OpenSSL version 1.1.0-pre6-dev
>> Here's a couple more ways things don't work as expected:
>>
>> # ./config CFLAGS="-mx32"
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>> target already defined - linux-x86_64 (offending arg:
> Here's a couple more ways things don't work as expected:
>
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32)
>
Here's a couple more ways things don't work as expected:
# ./config CFLAGS="-mx32"
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32)
# ./config -mx32
As far as I know, these are the two ways to detect the platform
because `uname` only provides x86_64/amd64 on some platforms:
# gcc -dM -E - -
> I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
> and
I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
and working from HEAD:
# git rev-parse HEAD
b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
It appears Configure is mis-detecting the platform, and it results in
a compile failure:
make
...
gcc -DDSO_DLFCN -DHAVE_DLFCN_H
43 matches
Mail list logo