Thanks for the three line upgracde recipe in
https://wiki.openssl.org/index.php/Code_reformatting
It's as simple as you stated, indeed.
The reformatting was a good thing to do. Also, it makes sense to me to apply it
to all
stable branches uniformly, in order to simplify cross-branch merging.
Hello,
Here is a recipe to guide you through the reformatting.
It worked nicely for me. I wrote a small bash shell script
which helped me do the bulk conversion, see attachment
Hope you'll find this information helpful.
In following I briefly describe the steps how you can
1) get your patches
I just posted an updated version of my script in a new
thread, titled
Minimizing the pain of reformatting your OpenSSL patches
Regards,
msp
On 03/19/2015 02:22 AM, Dr. Matthias St. Pierre wrote:
Hello,
Here is a recipe to guide you through the reformatting.
It worked nicely for me. I
Copy Paste error:
The name of the new branch is
${upstream}-post-auto-reformat
not
${upstream}-pre-auto-reformat
msp
On 03/19/2015 09:40 AM, Dr. Matthias St. Pierre wrote:
For every commit on the rebased branch, it does an automatic
conversion, placing the results onto a new branch
Sorry for that, another typo:
Please replace OpenSSL_1_0_1k by OpenSSL_1_0_1m below.
On 03/19/2015 09:40 AM, Dr. Matthias St. Pierre wrote:
3) After the script has succeeded, you can rebase your
reformatted branch to the head of the stable branch or
to the tag of the most recent release, e.g
Hello,
the upcoming security update imposes a special challenge to
all OpenSSL users who maintain their own patch sets.
The reason is the code reformat which has taken place in between
the last and the upcoming release, which renders existing patches
useless.
Hello,
my original post contained two typos. Also, the script reversed the order
of the commits due to a forgotten '--reverse'. (Probably, it was too late,
last night ;)
So here comes a repost with all corrections. Sorry for the inconveniences.
Regards,
msp
--
Hello,
the upcoming
Precisely the versions as stated in
https://openssl.org/news/secadv_20150709.txt are affected:
This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.
OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to
Dear Mr. Henson,
I noticed that for OpenSSL 1.0.2x and 1.0.1x on Windows the FIPS capable
libeay32.dll
does not export any of the FIPS_drbg_*() functions, although they are officially
documented by the OpenSSL FIPS 2.0 User Guide.
Is this an oversight or was this done on purpose? (IOW, is it a
developers?
Thank you in advance,
Regards,
Matthias St. Pierre
On 08/26/2015 05:14 PM, Dr. Matthias St. Pierre wrote:
>
> Dear Mr. Henson,
>
> I noticed that for OpenSSL 1.0.2x and 1.0.1x on Windows the FIPS capable
> libeay32.dll
> does not export any of the FIPS_drbg_*() f
On 06.07.2016 09:37, Stuart Douglas wrote:
> Hi everyone,
>
> I am trying to implement a generic Java SSLContext that is backed by
> OpenSSL that uses dynamic loading to link to OpenSSL.
>
> This works well on Linux, however I am running into "no
> OPENSSL_Applink" issues on Windows. According
You might be interested in the following two blog posts:
https://www.openssl.org/blog/blog/2017/07/25/fips/
https://www.openssl.org/blog/blog/2017/08/17/fips/
Matthias
On 25.01.2018 16:34, xemdetia . wrote:
> Hey all,
>
> Back in 2016 there was a news post found
>
Hi Mark,
I guess your problem is that you are trying to build OpenSSL 1.1.0 with FIPS.
Only OpenSSL 1.0.2 has FIPS support.
Regards,
Matthias
Von: openssl-users Im Auftrag von Mark via
openssl-users
Gesendet: Mittwoch, 22. August 2018 18:38
An: openssl-users@openssl.org
Betreff:
> Von: openssl-users Im Auftrag von The
> Doctor
> Gesendet: Dienstag, 11. September 2018 08:49
> An: openssl-users@openssl.org; openssl-...@openssl.org
> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3
>
> Will that combination occur?
Support for TLS 1.3 is a new feature in OpenSSL 1.1.1
Am 05.03.2018 um 20:39 schrieb Alan Dean:
> Thanks Matthias for your response.
>
> I have a different question:
>
> Per your suggestion in the previous email, FIPS_mode_set() can be
> moved inside of OPENSSL_init(), in order to force the FIPS mode
> enabled in the library level.
>
> However
Hi,
this issue was fixed in the OpenSSL 1.0.2 stable branch in commit
https://github.com/openssl/openssl/commit/18df0adda98f8f21cc494b4835c2817bcadbeb8a,
which will be part oft he next letter release. If you need it right away, you
can get it from the current stable branch on github.
; Im Auftrag von Dr.
> Matthias St. Pierre
> Gesendet: Dienstag, 13. März 2018 15:22
> An: openssl-users@openssl.org
> Betreff: Re: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit
> Platform
>
> Hi,
>
> this issue was fixed in the OpenSSL 1.0.2 stable branch
Hello Jan,
the canonical way to create the hash of the public key is to use
d2i_PUBKEY() to save the public key in (binary) DER format and then
calculate the hash of that using
EVP_DigestInit()/EVP_DigestUpdate()/EVP_DigestFinal().
Hope that helps,
Matthias
Am 21.03.2018 um 14:42 schrieb Jan
On 05.03.2018 10:46, Alan Dean wrote:
> Question 1: Is it even feasible to make the FIPS mode always enabled
> for the whole OpenSSL library (i.e. for both libcrypto and libssl), so
> that most the applications which dynamically linked to libcrypto and
> libssl will be automatically use OpenSSL
On 05.03.2018 11:57, Dr. Matthias St. Pierre wrote:
>
> However, I am sceptical whether this approach will be accepted,
> because there are (at least) two potential problems:
>
> * Normally, it is mandatory to check the result of FIPS_mode_set() or
> FIPS_mode() to en
Am 05.03.2018 um 19:55 schrieb Alan Dean:
> Thanks a lot Matthias for the suggestion.
>
> I have few follow-up questions below:
>
Please see my other replies.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Am 05.03.2018 um 20:07 schrieb Salz, Rich via openssl-users:
>
> * Did you mean if an application uses the low level crypto algorithm
> functions (e.g. SHA256_Init/ SHA256_Update/ SHA256_Final) then
> they won't work under FIPS mode (and hence may cause unpredictable
> issues)?
>
>
Hi,
a lot of structures where made opaque going from 1.0.2 to 1.1.0.
This means, you will have to make changes to your program source code
to compile it against 1.1.0 or 1.1.1.
For details, see https://www.openssl.org/docs/faq.html#PROG2
HTH,
Matthias
> -Ursprüngliche Nachricht-
>
Oh, I should have read your mail until the end:
Are you upgrading from 1.0.0h or 1.1.0h? Your post mentions both versions.
> -Ursprüngliche Nachricht-
> Von: openssl-users Im Auftrag von Dr.
> Matthias St. Pierre
> Gesendet: Dienstag, 23. Oktober 2018 09:17
> An
> -Ursprüngliche Nachricht-
> Von: openssl-users Im Auftrag von Paul
> Dale
> Gesendet: Freitag, 5. Oktober 2018 01:33
> An: openssl-users@openssl.org
> Betreff: Re: [openssl-users] Seeding before RSA key generation
>
> Not mentioned thus far is that if you are using 1.0.2 with FIPS
Final release is still scheduled for September 11, see also the discussion on
openssl-project
https://mta.openssl.org/pipermail/openssl-project/2018-September/001010.html
HTH,
Matthias
Von: openssl-users Im Auftrag von Juan Isoza
Gesendet: Dienstag, 4. September 2018 09:09
An:
Thanks for the reminder, see https://github.com/openssl/web/pull/83.
Matthias
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -Ursprüngliche Nachricht-
> In the meantime:
>
>$ perl -ne 'print if (/^-BEGIN/../^-END/);' foo.pem |
>openssl asn1parse
>
> > On Sep 25, 2018, at 1:15 PM, Hubert Kario wrote:
> >
> > then it looks like the parser used in asn1parse -inform pem is non-
> >
> Particularly if you don't know exactly what one is looking for...
> { There is something amiss with BIO_addr_rawaddress... it's shift right.
> I don't see a problem in the HTML source though.. }
>
> Sure, google will find some things, but usually it's the wrong version, and
> one has to guess
> The docs site is screwed up.
Actually, it is screwed up for the older versions, not for 1.1.1:
In OpenSSL 1.1.0 and before, the pod files (the manual page sources)
would be located in /doc/crypto and /doc/ssl,
and only during the installation would be placed in the proper manX
subdirectory
> Generally I find everything I need in the source tarball and after the
> install is done everything anyone could want is installed on the system.
> As for 'sidenav' that sounds like someone actually has to go tweak stuff
> manually on some website. Sadly. Anyways, the source tarballs have
>
I agree with Kurt, except for one point:
> The RAND_bytes and RAND_status manpages can clearly be improved.
Both manpages got an update during the DRBG rewrite (by me) and I don't
see any contradiction. You bring it to the point yourself:
> So _IF_ it is seeded it is seeded...
It is true
> |Both manpages got an update during the DRBG rewrite (by me) and I don't
> |see any contradiction. You bring it to the point yourself:
>
> I had a superficial look yesterday, but i think i have to reread
> them in total, anyway.
Yes, please start with RAND(7) and RAND_DRBG(7).
> That is
Antonio,
did you debug the preinstalled openssl app or have you tried to debug your own
version, built with a debug configuration?
You get the best results in the debugger if you use the `debug-linux-x86_64`
config target and
after building (you only need to run `make`, not `make install`) run
Sorry, the command contains a little error: please replace `gdb …` by `gdb
–args …`:
util/shlib_wrap.sh gdb --args apps/openssl cms -sign -signer cert.pem
-inkey 101 -keyform engine -engine pkcs11
--
openssl-users mailing list
To unsubscribe:
> The paper does not list the CVE for the openssl vulnerability.
>
> Is there a CVE for this? What are the affected versions and in which
> version they were fixed?
A similar question has been asked at the end of the GitHub issue
https://github.com/openssl/openssl/issues/7739. As far as I know,
Short version: Just do 'make update' and the numbers will be added
automagically.
Long version: There is a script, 'util/mkdef.pl', which gets invoked by 'make
update'. It scans the header files
for new APIs an updates the .num files (libcrypto.num/libeay.num and
libssl.num) accordingly.
> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these
> various platforms, without any explicit initialization.
Yes, for the mentioned platforms, the default configuration is
`--with-rand-seed=os`, which means the DRBG automatically seeds
and reseeds
> After some searching and check, I've realized that openssl is not configured
> for different target architectures?
> I develop an application for Android using NDK(Native Development Kit).
> There is Configurations/15-android.conf inside openssl git repo, but could
> not be sure.
> Could
Hi Thomas,
> Unlike previous releases, this tar-gzipped file contains a 52 byte file
> called 'pax_global_header'. The contents of the file contain a single
> line of text:
>
> 52 comment=50eaac9f3337667259de725451f201e784599687
my extracted tarball does not contain this file. This seems to be
> Uhm, I'm confused. I thought we were talking about 3.0?
Well, the original post started at FIPS 2.0:
> I am using openssl-fips-2.0.16 and openssl-1.0.2e.
https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html
But it seems like the discussion in the thread has drifted a
> -Ursprüngliche Nachricht-
> > >I always understood "FIPS-capable OpenSSL" to refer specifically to an
> > OpenSSL compiled with the options to incorporate the FIPS canister
> > module, not just any OpenSSL build that might be used in FIPS compliant
> > applications (as
If the compilation errors are in openssh, then it might be better to ask the
openssh people.
Also, posting the precise error messages by the compiler would be of great help.
As for your citation below: It seems to state that building against version
1.1.0 and 1.1.1 is supported,
while building
Yay,
there are some controversial discussions taking place on
https://github.com/openssl/openssl/issues/9078
It would be great if you could join us and provide more details about the
circumstances of your issue. In particular, information like kernel/os version
and whether the significant
> -Ursprüngliche Nachricht-
> I don't thing I have seen this before :
>
> beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf -
> tar: pax_global_header: typeflag 'g' not recognized, converting to
> regular file
> beta $
>
> Must be a gnu tar thing?
Hi Dennis,
it's not a bug, it's a
> I think I have tracked down the change in 1.1.1c that is causing this.
> It is the addition of the DEVRANDOM_WAIT functionality for linux in
> e_os.h and crypto/rand/rand_unix.c. lighttpd (libcrypto) is waiting in
> a select() call on /dev/random. After this eventually wakes up, it then
>
> To workaround the /dev/random blocking issue, you can just add:
>
> -DDEVRANDOM="\"/dev/urandom\""
>
> as a parameter to ./Configure
>
> This will remove the special handling of /dev/urandom and /dev/random
> in 1.1.1c.
Tomáš, Jay,
I'm afraid this suggestion won't help, because
Correction, Tomáš was correct: there is an ` # ifndef DEVRANDOM` surrounding
the problematic code:
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L25-L34
Neverthelesss, I still think this code needs to be changed, because the seeding
should just work correctly out-of-the-box
I think nobody of us needs to be convinced anymore that making it a 'double'
was a bad idea.
But the RAND api is very ancient and changing the argument type would be a
breaking change.
That's why we didn't dare to touch it when we overhauled the RNG implementation
for 1.1.1,
because we tried
> > I think this is a problem with the 20-test_enc.t Test and not with OPENSSL.
> >
> > Can you please help me to fix the Test ?
> >
>
> Did you enable zlib by any chance? If so it could be this:
>
> https://github.com/openssl/openssl/issues/9866
>
> No resolution as yet.
>
> Matt
If you
> For an application linked to FIPS capable OpenSSL,
> 1) After calls to FIPS_mode_set() and FIPS_mode() both succeed, is it good
> practice to call FIPS_selftest()? Or is this redundant call?
>
> 2) Did come across documentation which only hinted that FIPS_mode_set() calls
> FIPS_selftest()
> We are using OpenSSL APIs in our product code. We are not making any changes
> in OpenSSL.
> Our product code is a C++ code and it makes use of openSSL APIs for some
> functionality.
Local headers (like "ssl_locl.h" and "packet_locl.h") are *NOT* part of the
official OpenSSL API.
Please
Hello,
since we got a few bug reports by now about this issue on GitHub,
I thought it might be a good idea to spread the information a little bit:
It is a known issue that the 20-test_enc.t test fails in OpenSSL
version 1.1.1d if zlib support is enabled (see [1]).
Meanwhile, the bug has been
> OpenSSL code is compiling without any issues. When it is used from our
> product code and while compiling using C++ compiler, the issue is seen.
As I wrote previously, the error you posted was caused by the fact that you
are compiling Ansi C (a.k.a ISO/IEC 9899:1990, a.k.a C90) source code
> Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' :
> cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to
> pointer to non-'void' requires an explicit cast
Is it possible that your error message was copied incorrectly? Line 429 is an
assignment
OpenSSL is using regular base64 encoding, see for example
https://www.openssl.org/docs/man1.1.1/man3/EVP_EncodeInit.html
But if you need base64url encoding, no problem: a simple string replace will
help.
https://brockallen.com/2014/10/17/base64url-encoding/
Regards,
Matthias
Von:
Just noticed your OpenSSL version: it is _very_ old and not supported anymore.
its successor, OpenSSL 1.0.2, will be EOL by the end of this year.
The current stable LTS version is OpenSSL 1.1.1.
Matthias
Von: openssl-users Im Auftrag von Benjamin
ENTE
Gesendet: Freitag, 18. Oktober 2019 08:51
P.S: My answer to your original question applies to 1.0.1 as well:
https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/doc/crypto/EVP_EncodeInit.pod
Von: openssl-users Im Auftrag von Dr.
Matthias St. Pierre
Gesendet: Freitag, 18. Oktober 2019 09:10
An: Benjamin ENTE ; openssl-users
Hi Tim,
> However, when I run the tests there appears to be failures.
>
> Extract of the make test output below:
>
>
> ../test/recipes/20-test_enc.t ..
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/172 subtests
Your test failure looks like issue
> > The easiest way to obtain the fix is to update to the current head of the
> > 1.1.1. stable branch.
> > https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable
>
> I think you meant to link to the 1.1.1 branch not 1.0.1!
>
>
It’s the passwort which protects the p12 file. If you were given a ‘PIN’ for
your pfx file, try that.
OpenSSL calls it ‘import passwort’, because it is importing from p12 format and
exporting to
pem format.
Two remarks about those three commands:
If you omit the `-nodes` argument in the
Hi,
in the body of the message you just sent us, you find a detailed description
how to unsubscribe:
To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
FYI: I restarted the discussion in #7946
https://github.com/openssl/openssl/issues/7946#issuecomment-603545804
Matthias
> For each new release, it seems that the tarball is published in the
> "/source" directory (website) while the previous one is moved to
> "/source/old/".
>
> Would it be possible that all releases land in "/source/old",
> including the new one when published? After all anything is more or
> less
Hi,
> I am beginner in openssl and I am porting openSSL-1.1.1d in vxWorks-6.9. So
> as suggested I have defined "OPENSSL_RAND_SEED_NONE" flag, as for vxWorks
> 'none' is only supported but after doing so I am observing
> "rand_pool_entropy_available()" returns 0 which further leads to failure.
>
> Indeed, one workaround for your application would be to seed and reseed
> the random generator manually using RAND_bytes(), ...
Correction, I meant to say ".. using RAND_add()..."
> -Original Message-
> From: openssl-users On Behalf Of Dr.
> Matthias S
Hmmm... that might be a remnant which was forgotten during the reorganization
of the
header files, see commit [1] of pull request [2].
It tested it on master, it seems like the empty directories are created by the
Configure script.
Would you mind opening a GitHub issue for it?
Regards,
> I think it would be better to just add a comment that the older branch
> changes are tracked elsewhere.
The note is already present, it's in the second paragraph of
https://www.openssl.org/news/changelog.html
but it is confusing nevertheless and it would be more useful if the
entire information
> On 22/09/2020 15:03, Michael Wojcik wrote:
> > changelog.html hasn't been updated since 1.1.1e.
> >
> > https://www.openssl.org/news/changelog.html#openssl-111 shows:
>
> That's the master Changelog. Confusing I know.
>
> The link to the 1.1.1 Changelog is at the top of the page.
It is
> The proper protocol would be to just sign the binary by your private
> RSA key and encrypt it with a symmetric key, that you directly pre-
> distribute to your recipients via the same channel that you now use to
> distribute your public RSA key.
I agree with Tomáš, just would like to emphasize
> Does my test program do anything interesting on your system?
No. Except for compiling with warnings ;-)
> Python has:
> typedef void (*freefunc)(void *);
>
> That looks weird to me, but I'm not a language guy.
That's simply a C type definition for a pointer type named `freefunc`, which
can
Thomas,
> I consider this a bug, of course, but at least now I know what's causing it
> and how to work around it.
thanks for sharing your analysis. Would you mind creating a GitHub issue for
the hang?
https://github.com/openssl/openssl/issues
Matthias
From: openssl-users On Behalf Of
> Grepping through all of my OpenSSL sources, I see only the
> above mention and one in 'Configurations\10-main.conf'.
>
> So how/when is 'gdi32.dll' needed? Maybe it was true in the old-days?
My guess is that you are right and that it was needed only for the function
readscreen(), used by
: Chris Outwin
Sent: Monday, December 28, 2020 9:43 PM
To: Dr. Matthias St. Pierre
Subject: Re: SHA256 openssl-1.1.1i Checksum Error
Thank you for your prompt reply. Removing the quotes from VERSION=“1.1.1i”
allowed the script to run.
On Dec 28, 2020, at 12:49 PM, Dr. Matthias St. Pierre
John,
I guess you received this mail because you are subscribed to the openssl-users
mailing list.
(You might also be subscribed to the openssl-announce mailing list, but that's
less likely.)
To unregister from the list, please visit
https://mta.openssl.org/mailman/listinfo/openssl-users
Do you need to integrate the decryption into your own software, or are you just
looking for a possibility to monitor and view the traffic?
If it’s the latter, try and take a look at the SSL decryption support that
Wireshark provides.
https://wiki.wireshark.org/TLS
I have no experience with zsh, but it seems that quoting is handled differently
by zsh?
At least it looks like the double quotes ended up in the GET line and you
simply received
an HTTP 404 Not Found (which is the reason why your digest isn’t correct.)
HTH,
Matthias
> GET
It’s the same. The correct full name is RSASSA-PSS, where ‘SSA’ stands for
Secure Signature Algorithm (IIRC) and ‘PSS’ for Probabilistic Signature Scheme
Regards
https://en.wikipedia.org/wiki/PKCS_1#Schemes
https://datatracker.ietf.org/doc/html/rfc4056
From: openssl-users On Behalf Of Eddie
Correction: It seems like the naming of the TPM_ALG_* constants is a little bit
inconsistent: According to
https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf
* TPM_ALG_RSASSA refers to RSASSA-PKCS1-v1_5
and
* TPM_ALG_RSAPSS refers to RSASSA-PSS.
Just a short heads-up to all users testing and developing for OpenSSL 3.0:
The defaults for the configuration options 'fips' and 'makepend' are going to
change on the master branch soon
(i.e., before the release of 3.0.0 alpha16): they will be disabled by default.
If your developer workflow or
' option remains enabled by
default.
Matthias
https://github.com/openssl/openssl/pull/15050
> -Original Message-
> From: openssl-users On Behalf Of Dr.
> Matthias St. Pierre
> Sent: Tuesday, April 27, 2021 9:50 PM
> To: openssl-users@openssl.org
> Subject: configura
Re Q1: I want to know is there any way to avoid this problem? I want thread T2
to call default RAND methods and avoid calling methods set by thread T1. This
is not only for RAND methods, but for any other methods.
First of all, I agree with Pauli: your first question should be, why do you
need
Vishwanath,
have you already tried to simply use the default RAND_METHOD and not to replace
it by your own? Except for the initial seeding(*), the thread local DRBGs
should operate for a long time without blocking and without interfering with
each other. Even if the thread local DRBGs reseed,
> It isn't possible to do what you are wanting. RAND_METHOD replaces the RNG
> everywhere. It cannot be done on a per thread process.
Well, technically it *is* possible. However, I'm still in doubt whether it is
really necessary and should be done.
The following example assumes you are
It seems a bit outdated nowadays to publish daily snapshots imho.
https://www.openssl.org/source/snapshot/
Instead of maintaining those snapshots, couldn't we just advertise the GitHub
download links?
Any branch or commit can be downloaded easily as ZIP or compressed TAR file,
whatever you
To unsubscribe, visit https://mta.openssl.org/mailman/listinfo/openssl-users
Regards
From: openssl-users On Behalf Of Kingsley O
Sent: Wednesday, August 25, 2021 6:06 PM
To: Turritopsis Dohrnii Teo En Ming
Cc: openssl-users@openssl.org
Subject: Re: Testing
Please remove my email from this
I’ll take care of it and ask the administrator to remove it manually if
possible.
From: Kingsley O
Sent: Thursday, August 26, 2021 3:41 PM
To: Dr. Matthias St. Pierre
Cc: openssl-users@openssl.org
Subject: Re: Testing
Didn't work..:-(
Did not receive email to complete the unsubscribe process
The README file in the test directory contains some hints how to troubleshoot
test failures.
Look which test is failing and rerun it in verbose mode:
make tests V=1 TESTS=testname
https://github.com/openssl/openssl/blob/master/test/README.md#test-failures
Hope that helps,
Matthias
If you add the `--debug` argument to your configure command and rebuild OpenSSL,
you will get a library with debug information and without optimization.
https://github.com/openssl/openssl/blob/master/INSTALL.md#build-type
HTH,
Matthias
From: openssl-users On Behalf Of Ma Zhenhua
Sent:
> Can you give a MWE for what you are trying to achieve?
I guess that "minimal working example" is the correct choice from the
gazillions of possible meanings of "MWE"?
Regards,
Matthias
[1] https://www.acronymattic.com/MWE.html
[2] https://www.abbreviations.com/MWE
smime.p7s
Hi all,
today I learned that nmap has a nice feature to enumerate the protocol versions
and cipher suites supported by the peer (see below).
Is there a comparable elegant way to obtain the same results using the `openssl
s_client` tool?
Matthias
--
$ nmap -script ssl-enum-ciphers -p 443
> "Comparable elegant" is underspecified.
(I guess, "Comparably elegant" would have been grammatically more correct.)
> Perhaps try testssl.sh (https://testssl.sh/)? It has various options for
> reducing the number and types of tests it runs. We've used it for
> profiling internal TLS-enabled
For OpenSSL 3.0, it's better to use util/wrap.pl instead.
(Note: util/wrap.pl is created from util/wrap.pl.in by the Configure command)
> -Original Message-
> From: openssl-users On Behalf Of Dr.
> Matthias St. Pierre
> Sent: Saturday, December 18, 2021 9:11 AM
>
. And with the given
information,
you should be able to figure out what precisely happens in your original case
using
ldd an/or strace.
Matthias
> -Original Message-
> From: openssl-users On Behalf Of Dr.
> Matthias St. Pierre
> Sent: Saturday, December 18, 2021 9:20
Hal,
> But when I run
> ./apps/openssl version -d
> it says:
> OPENSSLDIR: "/usr/local/ssl"
> I was expecting /etc/pki/tls from the Configure line above.
>
> What am I missing? How do I tell it where to find the default certificates?
It is very likely that your binary is actually loading
It's a little bit strange though that according to Google the page was cached
on 2. Nov 2021, which is only two and a half weeks ago.
Have the manual pages for 1.1.0 been deleted only recently?
More strangeness: the side bar for the master and 1.1.1 manpage displays the
text "[an error occurred while processing this directive]"
https://www.openssl.org/docs/manmaster/man3/X509_get_ext_d2i.html
https://www.openssl.org/docs/man1.1.1/man3/X509_get_ext_d2i.html
smime.p7s
Description:
Hi,
you can find this sort of information in the manual pages, either on you
UNIX*SH operating system,
or online on our website:
HTH,
Matthias
https://www.openssl.org/docs/man1.1.1/man3/PEM_read_bio_X509.html:
RETURN VALUES
The read routines return either a pointer to the structure read or
Second attempt
> #17184 - QUIC API Design
> https://github.com/openssl/openssl/pull/17184
>
> #17185 - QUIC Event Loop Design
> https://github.com/openssl/openssl/pull/17185
> > -Original Message-
> > From: openssl-users On Behalf Of Matt
> > Caswell
> > Sent: Friday, December 3,
Sorry, the links to the pull requests are broken. This will be fixed as soon as
possible.
Here the correct links:
#17184 - QUIC API Design
https://github.com/openssl/openssl/pull/17184
#17185 - QUIC Event Loop Design
https://github.com/openssl/pull/17185
> -Original Message-
> From:
1 - 100 of 111 matches
Mail list logo