On Tue, 2018-01-16 at 19:31 +, Sands, Daniel wrote:
> On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote:
> > OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE
> > OF. Ouch! Will that cause interop problems if we change it? (I
> > don’t remember the DER encodi
On 09/28/2017 12:21 AM, Steffen Nurpmeso wrote:
> Hello.
>
> Tomas Mraz wrote:
> |I would like to restart the discussion about possibilities of system-
> |wide configurability of OpenSSL and particularly libssl.
> |
> |Historically OpenSSL allowed only for configu
On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote:
>
> > 1.2. This also opens the path to stronger key derivation (PBKDF2)
> > 2. During decryption, if no header block is present, and no message
> > digest was specified, the default digest SHOULD be MD5.
>
> Should it? What about compatibi
I would like to restart the discussion about possibilities of system-
wide configurability of OpenSSL and particularly libssl.
Historically OpenSSL allowed only for configuration of the enabled
ciphersuites list if application called appropriate API call. This is
now enhanced with the SSL_CONF API
On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:
> On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev
> > wrote:
> > > I understand the concern. The issue I am wrestling with is
> > >
On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev wrote:
> I understand the concern. The issue I am wrestling with is strict
> compatibility with the existing code. Does anyone really *want* the
> RNG’s to not reseed on fork? It’s hard to imagine, but maybe
> somewhere someone is. A
On Fri, 2017-07-21 at 15:56 +0200, Johannes Bauer wrote:
> I've changed my code now to also use the (mutable) new
> EC_KEY_METHOD*,
> which doesn't give a diagnostic. Regardless, I believe that the first
> parameter of EC_KEY_METHOD_get_sign should be const EC_KEY_METHOD*,
> not
> EC_KEY_METHOD*.
Just a notice for anyone interested,
In Red Hat Enterprise Linux 6 and 7 we disabled support for insecure
hashes for digital signatures. Basically signatures with MD5, MD4, MD2,
and SHA0 will fail verification by default. We could not switch off the
support for these weak hash algorithms completel
.x, but allowing such usability changes for command-
line and also allowing things like removal of obscure or insecure
features but keeping the function signatures intact (they would simply
return errors). And also keep the library SONAME so dependencies do not
need to be rebuilt.
And spare full break
pproach? Mozilla NSS
and GnuTLS can use this PKCS11 module directly as a trust store, we
would like to add the same functionality to OpenSSL.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll n
everally limited by
other means then perhaps it really makes no sense to replace the
existing algorithm. But we need to know this first.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never kn
? Is that it?
I also would not be too much worried - the API call should not be
completely universal - the application should know whether it is
loading a certificate or private key. It should just be able to use a
single call to load a certificate in PEM, DER, or whatever other
possible d
Hi,
I'm trying to port OpenVPN to OpenSSL-1.1.0 API.
Unless I overlooked something the new OpenSSL-1.1.0 does not allow
access to the ex_nscert data of the X509 object. Would it be possible
to add such function to the API?
Regards,
--
Tomas Mraz
No matter how far down the wrong road y
> let us know.
> Hm, not *quite* enough time for me to get a flight to Berlin today...
> and I'd have a three-year-old in tow.
I have a similar problem although I could reach Berlin by train which
is a little bit easier and cheaper. I would be very happy to meet w
not affecting directly the
code that is being compiled would be replaced with what is placed into
CFLAGS/LDFLAGS. But things like -D would be kept from the config target
information.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
I would like to join this request as maintainer of OpenSSL for Fedora
and Red Hat Enterprise Linux. It would clean up things for us as well.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You
ng at the rest of the API).
You might get such kind of backport to something that still evolves
such as (RHEL/CentOS 7) however you would not get it in older releases
(RHEL/CentOS 5 and most probably RHEL/CentOS 6 either).
So you will still be facing the issue that th
ng at the rest of the API).
You might get such kind of backport to something that still evolves
such as (RHEL/CentOS 7) however you would not get it in older releases
(RHEL/CentOS 5 and most probably RHEL/CentOS 6 either).
So you will still be facing the issue that th
se-after-free in your
code.
I agree that this sequence - get + set should be more precisely
documented as forbidden but that's it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
SA_set0_key(rsa, n, e, d);
>
> rsa is left with n and e pointing to unallocated storage.
This is programmer error in your code because the RSA_get0_key is
documented to just return internal data and must not be freed. Thus
you're not allowed to pass the returned values to RSA_set0_key(
uch as calculatig d */
> RSA_set0_key(rsa, NULL, NULL, d);
Yes, this is a reasonable solution and the commit in GH#995 looks sane.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll
the intention.
>
> Agreed that we could make sure not to free the pointers in that case.
In that case this should be properly documented so the users of the API
can depend on it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
the intention.
>
> Agreed that we could make sure not to free the pointers in that case.
In that case this should be properly documented so the users of the API
can depend on it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
ogic need to be done for all the RSA_set0_*
> functions as well as
> rsalz> > the DSA_set0_* functions.
> rsalz>
> rsalz> That seems like a bug we should fix.
>
> No, it's by design:
>
Then perhaps there should be a function to set only the private part of
the RSA
ogic need to be done for all the RSA_set0_*
> functions as well as
> rsalz> > the DSA_set0_* functions.
> rsalz>
> rsalz> That seems like a bug we should fix.
>
> No, it's by design:
>
Then perhaps there should be a function to set only the private part of
the RSA
the
> engine into a separately managed repo (as has happened recently with
> the
> GOST engine).
>
> If I don't hear from anyone I will remove these.
As far as I know there are some customers using the Chil engine with
RHEL (openssl-1.0.1).
--
Tomas M
; > to be any future calls to OpenSSL before the process exits.
>
> Maybe EVP_cleanup() and other similar explicit deinit functions
> should
> be deprecated, and do nothing in 1.1.0? The auto-deinit capability
> should handle it. That way you would not need to do anything
> &q
matically handled.
What if the server wants to discard all the application data that was
sent before the renegotiation completed? Or how the server can
recognize which part of data was received before renegotiation
completed and which after it?
--
Tomas Mraz
No matter how far down the wrong road you&#x
The attached patch provides documentation of some of the currently
undocumented speed options.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though
hat having the API compatibility would be really useful thing
easing porting application code to 1.1 branch.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll n
t be even reasonable to move the implementations into
the libcryptolegacy.so however I am not sure this change is worth it for
1.1.0.
I believe the maintenance costs for pure C implementations in such
separate libcryptolegacy or even in the main C library would be quite
minimal. I would also expect the
=0x7ED8220B478B (i.e. the Intel CPU bit is set)
it works fine and the AVX+SSSE3 codepath is taken.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1278194 for
details.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn
l streams of random numbers among
forked processes. If there is a buffering of data pulled from the kernel
RNG it is not sufficient to just say that all the data are pulled from
the kernel and thus unique.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
supported key lengths, etc.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
___
openssl-bugs-m
ql server hardcodes 512 bits DH parameters. That's
insecure and connect is prevented by the LOGJAM fix. You can configure
the server to not use DH ciphersuites as a workaround, or patch the
mysql server to use at least 1024 bits DH parameters.
--
Tomas Mraz
No matter how far down the
ql server hardcodes 512 bits DH parameters. That's
insecure and connect is prevented by the LOGJAM fix. You can configure
the server to not use DH ciphersuites as a workaround, or patch the
mysql server to use at least 1024 bits DH parameters.
--
Tomas Mraz
No matter how far down the
unsigned char key[HMAC_MAX_MD_CBLOCK];
> > > } HMAC_CTX;
> >
> > Why is separate key_init needid? Could we not use md!=NULL or
> > key_length!=0 checks to see if the context is initialized?
>
> Seems it'd be along with the line to just use key_length inst
use
it on older RHEL releases. On the other hand the current set of
supported ciphers does not make it useful for future use anymore so I do
not care much if it is removed from openssl master branch. If you
properly announce that the support will be removed unless anybody
provides patch adding suppor
e any
problem with this. However I would expect these three ifdefs to work -
of course with OPENSSL_NO_EC implying the NO_ECDH amd NO_ECDSA. Although
I did not try it myself.
Tomas Mraz
___
openssl-dev mailing list
To unsubscribe: https://mta.openss
Hello OpenSSL developers,
can you please include this fix which although a trivial code change
nevertheless does have big impact on the encrypted key-wrapped data.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Tu
t; to trust (perhaps just one for a particular peer, rather than the
> usual browser bundle).
Please enlighten me how this case could be broken by this change of
default? If the trust anchor is not found in the trust list, the
intermediate that is sent by the peer is followed anyway.
--
Tomas Mr
OpenSSL maintainer I would say it is not worth fixing in
OpenSSL. We will rebase to 1.0.2 final in Fedora Rawhide once it is
released.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never kn
OpenSSL maintainer I would say it is not worth fixing in
OpenSSL. We will rebase to 1.0.2 final in Fedora Rawhide once it is
released.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never k
penSSL and developing applications with OpenSSL.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
_
ine of SSLv23_method() and not the other
way around. Then in 1.x branch the legacy things might be removed if
appropriate.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
led for it. I am not sure what
would be the proper fix though.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never kn
he failure info text.
The attached patch fixes these minor bugs.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff --git a/crypto/ts/ts_rsp_
HE-RSA-AES128-GCM-SHA256 in the cipher list, it would be
correctly sent in the hello and chosen for the connection. I can't see
anyone using such specification in real world.
Basically what you specify is what you get.
--
Tomas Mraz
No matter how far down the wro
Hi,
during the review of OpenSSL commits I found this one:
https://github.com/openssl/openssl/commit/22a10c89d7c3f951339c385d57cc8fd23c0a800b
There is unfortunately not much detail in the commit message. Could this
be a possible security issue? Can you please clear that up?
Thanks,
--
Tomas
t.
>
> I withdraw my support for making -days take a fractional argument, given
> the behavior of the existing deployed base.
I agree with that as well. I did not look at the actual code in openssl
so I did not know that the fractional argument with the current version
does not er
e '-valid' to '-duration' .
> I'll get back on this in mid August.
What about just supporting float number argument for -days (0.5 for 12
hours certificate validity)? That should be fairly simple. In the first
step. And add something l
that possibly some distros
> define
> PURIFY in their production builds. Anyone know of an example where this is
> used
> in a production build?
We use -DPURIFY in regular openssl packages in Red Hat Enterprise Linux
and Fedora.
--
Tomas Mraz
No matter how far dow
cense, they can even
write similar tools themselves. So once is something found by Coverity
scan it should be considered as public knowledge anyway. Manual review
by real people is something very different.
--
Tomas Mraz
No matter how far down the wrong r
set to ALL
> those still get disabled: the only way to reenable them is to set the security
> level to zero as well.
>
> Support is unfortunately only in master at present though.
Would it be possible to get it to 1.0.2? Or is that already closed for
enhancements? Or does it break ABI com
On St, 2014-06-04 at 13:03 +, Viktor Dukhovni wrote:
> On Wed, Jun 04, 2014 at 10:45:59AM +0200, Tomas Mraz wrote:
>
> > SSLv2 is disabled by default, however when you use the ALL cipher list
> > which is of course something you should not do but it happened in perl
> &g
On Út, 2014-06-03 at 16:41 +, Viktor Dukhovni wrote:
> On Tue, Jun 03, 2014 at 06:01:03PM +0200, Tomas Mraz via RT wrote:
>
> > openssl advertises ECC ciphersuites in SSLv2 client hello if ssl23
> > method is used. This is incorrect because the TLS extensions that
>
hello.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff -up openssl-1.0.1e/ssl/s23_lib.c.ssl2noec openssl-1.0.1e/ssl/s23_lib.c
--- open
was a way to set the cipher preference string for these
https clients it would be extremely hard and error prone to set the list
for each of them individually.
--
Tomas Mraz
No matter how far down the wrong road you&
support in the cipher string? I'd
like to add the support to Fedora openssl package but we would like to
see it upstreamed sooner or later.
Thanks,
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
Heh, good :)
As we both came independently to the same patch we can declare it right
and perhaps the openssl upstream developers can finally commit it to the
git repository.
__
OpenSSL Project htt
Heh, good :)
As we both came independently to the same patch we can declare it right
and perhaps the openssl upstream developers can finally commit it to the
git repository.
__
OpenSSL Project http
patch fixes this bug.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff -up openssl-1.0.1e/apps/req.c.keylen openssl-1.0.1e/apps/req.c
--- openssl
lse if (!strcmp(value, "oaep"))
> pm = RSA_PKCS1_OAEP_PADDING;
>
> This appears to be a cut and paste error.
No, this is actually a fix for typo 'oeap' in previous versions.
--
Tomas Mraz
No
27;!' operator.
> >
>
> Yes it should, sorry about that. Fixed now.
But given skipping the locking in the FIPS mode doesn't that mean that
the reseed operation is now not being protected under lock at all? The
FIPS DRBG does not lock before calling the add/reseed callbacks.
-
tes(). However MD rand uses
CRYPTO_w_lock(CRYPTO_LOCK_RAND); in ssleay_rand_bytes().
This leads to double locking the CRYPTO_LOCK_RAND which can mean
undefined behavior unless for example in case of pthreads the mutex type
used is PTHREAD_MUTEX_RECURSIVE.
--
Tomas Mraz
No matter how far down the wrong r
>
> But if -4 worked and -28 fails, you really should look what
> fedora changed between those releases.
The -4 worked because the RDRAND engine was erroneously completely
disabled in the Fedora build. Only after the enablement of it the bug in
the CPU detection could manifest.
-
? Or is
the test not needed because in real life situation this cannot happen? I
suppose it might happen if the key is not renegotiated during lengthy
connections with transfer of data in TB range?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn
ck that could be prevented only by reseeding on forks
(or when a pid change is detected).
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
___
X509_get_pubkey() should be tested for NULL return.
But given the X509_set_pubkey() call later in the function - does it
really make sense to copy the parameters when they are overwritten
anyway? I suppose the code could be dropped altogether.
--
Tomas Mraz
No matter how far down the wrong road you&#x
how_bug.cgi?id=918981
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project http://www.open
the default paths only if neither
-CApath nor -CAfile is specified.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.1c/apps/s_client.c.default-paths openssl-1.0.1c/apps/s_cli
; applications that need compression support to explicilty clear it with
> SSL_CTX_clear_options(ctx, SSL_OP_NO_COMPRESSION);
I agree this is the solution that should be used as this does not break
the ABI.
--
Tomas Mraz
No matter how far down the wrong road you'
The str member of EVP_AES_CCM_CTX structure stays uninitialized when aes
ccm is used with the vpaes backend causing it to crash when the str is
later called as it is non-NULL. The attached patch fixes the problem.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn
u really have to assume
> > Linux that categorically? In other words in context of multi-platform code
> > such as OpenSSL there is value in *not* assuming things.
> I think
> http://rt.openssl.org/Ticket/Display.html?id=2830&user=guest&pass=guest
> already fixes the bug, si
d thus the comparison
fails and the fallback code for choosing some safe MTU value is not
invoked.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turk
he capabilities
should be defined by the underlying installed library version and not
the version it was built against. Of course in case the application
needs to refer to API additions for the new functionality the situation
is different, but that is not the case of TLS1.1.
--
Tomas Mraz
No matt
ot know of any concrete cases where the client
is intolerant of the split.
> As for client side, arguably it would make things worth. I mean if
> client plays smart and implements 1/n-1 split itself depending on
> situation, e.g. not when using POST, then such split in libssl
ch will improve the compatibility of the case where
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not used however I have not seen
any reports, at least in our Bugzilla, that would ask for that. So it's
just a matter of preference whether you want to change the 0/n split to
1/n-1 one.
--
Tomas Mraz
No m
cleanup_entropy can't we just make sure that function treats a NULL
> parameter as a no-op instead?
Yes, that's surely possible as well.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
cleanup_entropy can't we just make sure that function treats a NULL
> parameter as a no-op instead?
Yes, that's surely possible as well.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
lid non-NULL pointer in this
case.
The attached patch prevents returning invalid non-NULL pointer from the
fips_get_entropy() function.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-
rsions of openssl to be ABI compatible. They
compare the version that they were compiled against to the version
reported by the library. They usually ignore only the patch level number
(abcde...). We had to patch the version number in the library to stay
constant. I suppose these application
he RT queue is moderated. So you just need to wait till the moderator
looks at it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
_
OpenSSL-1.0.1-beta2 build with no-srp option fails because there are
some missing #ifdef OPENSSL_NO_SRP directives in the s_server code. The
attached patch fixes this.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Tu
The attached simple patch moves the libraries that are not needed for
dynamic linking to the Libs.private section in the OpenSSL .pc files.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up op
The attached simple patch allows other possible syntaxes of XMPP
starttls headers to be recognized.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -ru openssl-1.0.0d.old/apps/s_client.c openssl-1
In some cases when a S/MIME message with broken MIME headers is
processed a NULL dereference in mime_hdr_cmp can happen. The attached
patch guards against this dereference.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn
The attached trivial patch adds missing check for load_certs_crls
failure in apps.c. It is applicable to 1.0.0 and 1.0.1 branches.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1
The attached patch changes the generated pkgconfig files so the
libraries needed for static linking are in Libs.private instead of Libs.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up op
ree
> that latest version is acceptable, right?
I forwarded your other questions to our virtualization developers.
However for the last question the answer is yes, the latest version is
acceptable.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
well. So we're safe to expose AVX bits to guest directly.
Signed-off-by: Sheng Yang
Signed-off-by: Avi Kivity
Latest KVM still exposes AVX, and sets OSXSAVE to 0. This gives the
guest
kernel the option, which is based on XSAVE. N
t AVX bit. Which means that the AVX instructions will be used in
the SHA1 code which then fail with SIGILL.
The OSXSAVE is also cleared so that means if the XSAVE test was just
dropped it would work.
--
Tomas Mraz
No matter how far
ed if XSAVE is 0, not 1. XSAVE being 0 also
> implies that AVX flag [as well as FMA and XOP] is 0, which is why is
> jumps to 'done' and not 'clear_avx'.
This assertion is unfortunately not true on RHEL-6 guests on AVX capable
CPUs in XEN VM.
--
Tomas Mraz
No m
The attached patch adds missing documentation for the -no_ign_eof
option.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.0e/doc/apps/s_client.pod.doc-noeof openssl-1.0.0e/doc
with 1/n-1.
Tomas Mraz
diff -up openssl-1.0.0e/ssl/s3_both.c.beast openssl-1.0.0e/ssl/s3_both.c
--- openssl-1.0.0e/ssl/s3_both.c.beast 2010-03-25 00:16:49.0 +0100
+++ openssl-1.0.0e/ssl/s3_both.c 2011-10-13 14:05:50.0 +0200
@@ -758,15 +758,12 @@ int ssl3_setup_write_buffer(SSL *s
Here is analysis by Paolo Bonzini:
I compared crypto/x86_64cpuid.pl and crypto/x86cpuid.pl, and the code in the
latter is wrong.
>From x86_64cpuid.pl:
mov %edx,%r10d # %r9d:%r10d is copy of %ecx:%edx
bt \$27,%r9d # check OSXSAVE bit
jnc
ss of FIPS validation independent from
the upstream FIPS validation. This just shares some parts of the FIPS
related code from the upstream module but it does not support the
upstream FIPS module.
Tomas Mraz
__
OpenSSL Project
st it if you're
interested.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.0e/ssl/s3_both.c.beast openssl-1.0.0e/ssl/s3_both.c
--- openssl-1.0.0e/ssl/s3_both.c.beast 2010-03-25 00:16:4
There is a missing initialization of a variable in the CHIL engine. In
case the uninitialized value of the variable answer is 'C' and there is
no prompt, the engine startup will erroneously fail.
The attached patch fixes this.
--
Tomas Mraz
No matter how far down the wrong road you
enSSL and OpenSSH modules modify
> FIPS_mode_set function, and this OpenSSL don't
> use FIPS_check_incore_fingerprint() call ?
Yes, we modified the OpenSSL code and the Red Hat Enterprise Linux
OpenSSL FIPS module is validated independently from the OpenSSL upstream
FIPS module.
--
Tomas
1 - 100 of 145 matches
Mail list logo
