Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases

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.

Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases

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

Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases

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

Re: [openssl-users] Minimizing the pain of reformatting your OpenSSL patches

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

Re: [openssl-users] Minimizing the pain of reformatting your OpenSSL patches

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

[openssl-users] Minimizing the pain of reformatting your OpenSSL patches

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.

Re: [openssl-users] FIXED: Minimizing the pain of reformatting your OpenSSL patches

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

Re: [openssl-users] question on Alternative chains certificate forgery (CVE-2015-1793)

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

[openssl-users] FIPS_drbg_*() are not exported from FIPS capable libeay32.dll on Windows (OpenSSL 1.0.2x and 1.0.1x)

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

Re: [openssl-users] FIPS_drbg_*() are not exported from FIPS capable libeay32.dll on Windows (OpenSSL 1.0.2x and 1.0.1x)

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

Re: [openssl-users] Dynamically loading OpenSSL on Windows

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

Re: [openssl-users] OpenSSL DRBG in FIPS mode confusion.

lags = OPENSSL_DRBG_DEFAULT_FLAGS; openssl-1.0.2k/crypto/rand/rand_lib.c:261:fips_drbg_flags = flags; and you can change it using void RAND_set_fips_drbg_type(int type, int flags). Regards, Matthias St. Pierre -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 3.0 Canister Status

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 >

Re: [openssl-users] error: void value not ingored as it to be crypto/err/err_all.c

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:

Re: [openssl-users] openssl 1.0.2 and TLS 1.3

> 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

Re: [openssl-users] Enable the FIPS mode in the library level

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

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 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.

Re: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform

; 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

Re: [openssl-users] Hashing public keys

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

Re: [openssl-users] Enable the FIPS mode in the library level

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

Re: [openssl-users] Enable the FIPS mode in the library level

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

Re: [openssl-users] Enable the FIPS mode in the library level

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

Re: [openssl-users] Enable the FIPS mode in the library level

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)? > >

Re: [openssl-users] How to compile 1.1.1 under Windows

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- >

Re: [openssl-users] How to compile 1.1.1 under Windows

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

Re: [openssl-users] Seeding before RSA key generation

> -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

Re: [openssl-users] openssl 1.1.1 release

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:

Re: [openssl-users] Manpages still say "pre-release"

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

Re: [openssl-users] Certificate format question?

> -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- > >

Re: [openssl-users] openssl 1.1.1 manuals

> 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

Re: [openssl-users] openssl 1.1.1 manuals

> 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

Re: [openssl-users] openssl 1.1.1 manuals

> 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 >

Re: [openssl-users] RNG behavior by default

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

Re: [openssl-users] RNG behavior by default

> |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

Re: [openssl-users] Possible bug in crypto/engine

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

Re: [openssl-users] Possible bug in crypto/engine

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:

Re: [openssl-users] The 9 Lives of Bleichenbacher's CAT - Is there a CVE for OpenSSL?

> 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,

Re: [openssl-users] Error: does not have a number assigned

Yes, that would be a good idea. Although it does not prevent merge conflicts,  at least the ordinals don't have to be renumbered every time. (That's the way we solved the problem  in our company.) On 27.11.18 15:58, Viktor Dukhovni wrote: On Nov 27, 2018, at 7:38 AM, Dr. Matthias St. Pierre

Re: [openssl-users] Error: does not have a number assigned

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.

Re: [openssl-users] RNG behavior by default

> 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

Re: [openssl-users] Build target architecture

> 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

Re: AW: OpenSSL version 1.1.1b published

On 27.02.19 10:09, Jan Ehrhardt wrote: Thomas J. Hruska in gmane.comp.encryption.openssl.user (Tue, 26 Feb 2019 23:07:53 -0700): On 2/26/2019 10:05 PM, Dr. Matthias St. Pierre wrote: Hi Thomas, Unlike previous releases, this tar-gzipped file contains a 52 byte file called

Re: AW: OpenSSL version 1.1.1b published

On 27.02.19 13:51, Jan Ehrhardt wrote: Matthias St. Pierre in gmane.comp.encryption.openssl.user (Wed, 27 Feb 2019 13:00:55 +0100): On 27.02.19 10:09, Jan Ehrhardt wrote: I ran into this using 7-Zip 18.05 (x64) on Windows, which is a fairly recent version. Thanks for the Updates about 7-Zip

AW: OpenSSL version 1.1.1b published

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

AW: AES-cipher offload to engine in openssl-fips

> 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

AW: AES-cipher offload to engine in openssl-fips

> -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

Re: Developers, a small request

On 13.03.19 21:09, Richard Levitte wrote: So yeah, we do need to remember that PRs go through the CIs before merging. Agreed, and thanks Rich for the polite reminder :-) Matthias

Re: Reg solaris support for openssl 1.1.1b

My guess is that your binary is loading the system's shared libraries. To find out whether this is the case, try     ldd bin/openssl If my assumption is correct, you might have to set the LD_LIBRARY_PATH explicitely. HTH, Matthias On 15.03.19 09:43, ramakrushna mishra wrote: Hi, I am

AW: Building openssh7.9p1 and above against openssl1.1.1b

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

Re: AW: Performance Issue With OpenSSL 1.1.1c

. On newer systems, `getentropy()` should be the method of choice, because it does not share the deficiencies of the `/dev/urandom` device. On 30.05.19 02:11, Dr. Matthias St. Pierre wrote: To workaround the /dev/random blocking issue, you can just add: -DDEVRANDOM="\"/dev/urandom\"&q

AW: AW: Performance Issue With OpenSSL 1.1.1c

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

AW: Slightly funny tar ball for openssl 1.1.1c ?

> -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

AW: Performance Issue With OpenSSL 1.1.1c

> 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 >

Re: Forthcoming OpenSSL Releases

On 29.05.19 15:05, The Doctor wrote: For the next branch of OpenSSL is it 1.1.2 or 1.2.0 ? The next major release will be 3.0.0. See https://www.openssl.org/blog/blog/2018/11/28/version for an explanation. Matthias

AW: Performance Issue With OpenSSL 1.1.1c

> 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

AW: Performance Issue With OpenSSL 1.1.1c

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

AW: why does RAND_add() take "randomness" as a "double"?

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

Re: RAND_seed buffer freeing

On 11.07.19 12:00, tobias.w...@t-systems.com wrote: I`ve one question regarding RAND_seed, the first parameter refers to a buffer, who is freeing that buffer afterwards? Can I free it after the call to RAND_seed or is this done by openssl? You own the buffer, OpenSSL only reads its

AW: Test failed with openssl-1.1.1d ../test/recipes/20-test_enc.t

> > 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

AW: FIPS_selftest() Usage

> 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()

AW: OpenSSL compilation errors in Windows

> 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

OpenSSL 1.1.1d: test 20-test_enc.t fails if zlib is enabled

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

AW: OpenSSL compilation errors in Windows

> 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

AW: OpenSSL compilation errors in Windows

> 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

Re: Problems porting Openssl 1.1.1d to zos.

On 11.11.19 16:42, Wendell Nichols via openssl-users wrote: Is there anyone on this group with experience with ebcdic platforms, specifically zOS?  I have built 1.1.1d on zOS and connections to my server work for firefox 60 but not newer versions.  I don't know exactly where the cut off is

Re: Problems porting Openssl 1.1.1d to zos.

Please see also GitHub issue #4154, in particular https://github.com/openssl/openssl/issues/4154#issuecomment-552838141

AW: Base64 or Base64url

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:

AW: Base64 or Base64url

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

AW: Base64 or Base64url

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

Re: Usage of Secure C (memcpy_s, strcpy_s etc) functions on OpenSSL

Hello Raja, according to our policy, the OpenSSL C source code needs to conform to ISO C90, which makes it impossible to adopt C11 features. Chapter 20: Portability To maximise portability the version of C defined in ISO/IEC 9899:1990 should be used. This is more commonly

AW: building OpenSSL 1.1.1 with -DPURIFY

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

AW: AW: building OpenSSL 1.1.1 with -DPURIFY

> > 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! > >

RE: How to split a pfx file into cert and key?

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

RE: Re:openssl-users Digest, Vol 62, Issue 6

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

RE: RAND SEED in vxworks6.9

FYI: I restarted the discussion in #7946 https://github.com/openssl/openssl/issues/7946#issuecomment-603545804 Matthias

RE: Have new release published in /source/old directory too?

> 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

RE: RAND SEED in vxworks6.9

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. >

RE: RAND SEED in vxworks6.9

> 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

Re: Empty directories

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,

RE: OpenSSL version 1.1.1h published

> 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

RE: OpenSSL version 1.1.1h published

> 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

RE: Asymetric crypto and OpenSSL 3.0 deprecated functions

> 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

RE: freefunc - name clash with Python.h

> 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

RE: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

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

RE: The need for 'gdi32.lib'

> 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

RE: SHA256 openssl-1.1.1i Checksum Error

: 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

RE: OpenSSL version 3.0.0-alpha10 published

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

RE: Use OpenSSL to decrypt TLS session from PCAP files

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

RE: SHA256 openssl-1.1.1i Checksum Error

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

RE: What's different between RSASSA and RSAPSS padding mode?

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

RE: What's different between RSASSA and RSAPSS padding mode?

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.

configuration options 'fips' and 'makedepend' disbled by default on master

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

RE: configuration options 'fips' and 'makedepend' disabled by default on master

' 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: Regarding RAND_set_rand_method

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

Re: Regarding RAND_set_rand_method (was: openssl-users Digest, Vol 77, Issue 6)

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,

RE: openssl-users Digest, Vol 77, Issue 6

> 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

RE: Maiising Daily Snapshots for 20210416

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

RE: Testing

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

RE: Testing

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

RE: Hi team, I modified openssl code and make test failed. What should I do with the failed cases. Thx in advance.

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

  1   2   >