Hello, how does openSSL determine the Record Layer Version used to initiate
a ClientHello message to the server? I believe the determination is made at
this level.
When testing using multiple implementations (Python Requests on a Debian
machine and `cURL --tlsv1.2 --tls-max 1.2` from macOS) I
|Updating 'Text::Template' from perl solved the problem, detailed in
https://github.com/openssl/openssl/issues/6641|
On 28/10/2020 16:40, Viktor Dukhovni wrote:
***
This email originates from outside Imperial. Do not click on links and
attachments unless you recognise the
On Wed, Oct 28, 2020 at 04:32:56PM +0100, Jakob Bohm via openssl-users wrote:
> Recently, the EJBCA developers publicly warned (via the Mozilla root store
> policy mailing list) other CA vendors that they had incorrectly implemented
> the handling of the "notAfter" X509 field, resulting in
On Wed, Oct 28, 2020 at 04:33:12PM +0100, Thibaut Appel wrote:
> install libcrypto.so.1.1 ->
> /rds/general/user/home/.linuxbrew/Cellar/openssl@1.1/1.1.1h/lib/libcrypto.so
> ar:
> /rds/general/user/home/.linuxbrew/Cellar/openssl@1.1/1.1.1h/lib/libcrypto.so:
> file format not recognized
Wild
I don't know exactly what environments the OpenSSL build targets, but a
writable /tmp is a POSIX requirement.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html
--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
Dear Viktor,
I did try to change that hard-coded /tmp.
make install now fails because of
link
/rds/general/user/home/.linuxbrew/Cellar/openssl@1.1/1.1.1h/lib/libcrypto.so
->
/rds/general/user/home/.linuxbrew/Cellar/openssl@1.1/1.1.1h/lib/libcrypto.so.1.1
install libcrypto.so ->
Recently, the EJBCA developers publicly warned (via the Mozilla root store
policy mailing list) other CA vendors that they had incorrectly implemented
the handling of the "notAfter" X509 field, resulting in certificates that
lasted 1 second longer than intended.
Prompted by this warning, I
On Wed, Oct 28, 2020 at 09:46:49AM +0100, Harald Koch wrote:
> Hello,
>
> I’ve been asked to support an optional feature when using S/MIME
> signed message transmission for (as they call it) „Algorithm
> identifier protection“, which is defined in RFC6211. As I’ve found no
> evidence in the
On Wed, Oct 28, 2020 at 09:48:37AM +0100, Thibaut Appel wrote:
> I uncovered a potential issue affecting the installation of OpenSSL from
> source, in the case the user is not allowed to write in the /tmp folder.
This build environment was not anticipated by the build system, which
employs:
Hi Thibaut,
there must be something else in your environment: I chmod’ed my /tmp to 770,
added a new user, checked that we cannot access /tmp, and successfully compiled
openssl-1.1.1h on a test machine. The reason could lie somewhere else than /tmp.
> Am 28.10.2020 um 13:13 schrieb Thibaut
Dear Harald,
Thank you for your answer.
In fact my environment variable TMPDIR was already set to an appropriate
folder, in my bash environment.
Did you mean it is meant to be set somewhere else at build or install time?
Output of perl --version gives me: This is perl 5, version 16,
Dear OpenSSL users,
I uncovered a potential issue affecting the installation of OpenSSL from
source, in the case the user is not allowed to write in the /tmp folder.
I'm trying to install on a cluster where permissions to '/tmp' is
restricted.
Is there an environment variable designed to
Hello,
I’ve been asked to support an optional feature when using S/MIME signed message
transmission for (as they call it) „Algorithm identifier protection“, which is
defined in RFC6211. As I’ve found no evidence in the headers of openSSL, I’m
asking you if this feature is available or planned.
13 matches
Mail list logo
