Re: [openssl-dev] ETA: TLS 1.3 release

There is motion towards a 2.4.26 release around month end, give or take two weeks. On Apr 19, 2017 4:57 PM, "Kurt Roeckx" wrote: > On Wed, Apr 19, 2017 at 02:57:13PM +0200, Stefan Eissing wrote: > > > > > Am 19.04.2017 um 14:14 schrieb Salz, Rich via openssl-dev < >

Re: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch

On Wed, Apr 12, 2017 at 1:26 PM, Salz, Rich via openssl-dev wrote: >> Did the no-fips option get removed by-design? Are the no-* corollaries going >> to be dropped going forwards? > > Yes. All FIPS support was removed. It could be brought back, and made a > no-op, if

[openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch

Did the no-fips option get removed by-design? Are the no-* corollaries going to be dropped going forwards? ../src/openssl-1.1.0git/config shared no-fips --libdir=lib --prefix=/opt/openssl110 Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version

Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

On Mon, Mar 20, 2017 at 5:41 PM, Jason Vas Dias wrote: > Hi - much thanks for many years of great OpenSSL releases, > but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k > release on the website as the 'latest / best OpenSSL release' - this just > wastes

Re: [openssl-dev] [openssl-users] Removing some systems

Just FTR... http://www.osnews.com/story/28933/Blue_Lion_new_OS_2_distribution_due_2016 Not that I'd take that as a mandate to preserve support... We are having the same internal dialog at the ASF httpd project and coming to the same conclusions. On Mar 17, 2016 1:36 PM, "Salz, Rich"

[openssl-dev] 'make test' broken in 1.0.2g/1.0.1s...

This isn't the most correct fix, however the new release broke the testfipsssl ability to verify that -ssl2 is not accepted for SSLFIPS_ENABLE requests, since this check now fails OK instead of failing NOK as it is supposed to... --- 1.0.2g/test/testfipsssl 2016-03-01 12:29:25 UTC (rev 8415)

[openssl-dev] Out-of-date [ req ] defaults in apps/openssl.cnf?

I note that on the 1.0.1q package openssl.cnf, default_bits is still 1024, while it has been updated to 2048 for the 1.0.2e release. Both still include no default_md, and I would expect that should now look like [ req ] default_md = sha256 default_bits = 2048 on both 1.0.1 and 1.0.2 future

Re: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

Please note my typo identified by a dev at httpd, Yann... A little note, probably some missing == here: +else if (meth = TLSv1_2_client_method()) +BIO_printf(fbio, "Upgrade: TLS/1.2\r\n"); +else if (meth = TLSv1_1_client_method()) +BIO_printf(fbio,

[openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL). Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've gone ahead and instrumented s_client to support this behavior (and noted a small optimization in the same logic stream for starttls support). Attached is the patch to

Re: OpenSSL 1.0.1 released

On 3/14/2012 12:27 PM, Bruce Stephens wrote: open...@master.openssl.org (OpenSSL) writes: [...] o Preliminary FIPS capability for unvalidated 2.0 FIPS module. I note that #2741 appears not to be resolved, so if you build on Windows and use --with-fipsdir=... then that probably

Re: [CVS] OpenSSL: OpenSSL_1_0_1-stable: openssl/ Configure

+1, I had applied this locally [sorry for delays] On 3/14/2012 5:20 PM, Dr. Stephen Henson wrote: OpenSSL CVS Repository http://cvs.openssl.org/ Server: cvs.openssl.org Name: Dr. Stephen

{hash}-x86_64.pl assembly scripts just too fragile

http://rt.openssl.org/Ticket/Display.html?id=2435user=guestpass=guest http://rt.openssl.org/Ticket/Display.html?id=2440user=guestpass=guest Are there plans to revisit this before 1.0.1 GA, and is anyone working on this broken schema? It seems the GA would be a great time to get this right. Also

Re: {hash}-x86_64.pl assembly scripts just too fragile

On 3/9/2012 1:45 PM, William A. Rowe Jr. wrote: http://rt.openssl.org/Ticket/Display.html?id=2435user=guestpass=guest http://rt.openssl.org/Ticket/Display.html?id=2440user=guestpass=guest Simpler is usually better... what specific behavior is the deleted code below trying to accomplish

Re: {hash}-x86_64.pl assembly scripts just too fragile

On 3/9/2012 4:55 PM, Andy Polyakov wrote: Also from win32's asm build, all of the script invocations forgot to include the nasm/masm(ml64) command line arg... What does it mean exactly? I'll get you a patch shortly, but in short, it meant that do_amd64 was emitting an ntdll.mak line to

Re: OpenSSL FIPS Module 2.0 status update

On 3/6/2012 8:43 AM, Steve Marquess wrote: On 03/06/2012 08:49 AM, Vanden, Michelle CTR USAF AFMC AAC/EBYC wrote: Hello Steve, Will the new certificate support that is has been tested in a Windows 7 That validation will include the following MS Windows platforms: Windows 7 32bit on

Windows 0.9.8t build still broken

Trivial patch to avoid this windows build failure; ms\uplink.c(43) : error C2220: warning treated as error - no 'object' file generated ms\uplink.c(43) : warning C4996: '_swprintf': swprintf has been changed to conform with the ISO C standard, adding an extra character count parameter. To use

Re: OpenSSL FIPS Module 2.0 status update

On 1/9/2012 7:38 AM, Steve Marquess wrote: It is not relevant ... an attempt to deal with a Microsoft Windows issue. We have since identified a better work-around that does not involve changes to the module code. Since we're probably going to be asked, here's the issue: we found that

Re: [openssl.org #2581] bug: Why do these 12 lines of Win32 code work on XP but hang forever in Vista and Windows 7?

On 8/18/2011 2:58 AM, Mike Nosler via RT wrote: Everything works fine on XP. The code stays in the second BIO_do_accept() waiting for a connection, and sending an HTTPS request from a browser causes BIO_do_accept() to return. On 32-bit Vista Home Premium and 64-bit Windows 7, the second

Re: Which tar.gz file I need for OpenSSL FIPS Object Module?

On 7/15/2011 6:48 PM, Tatiana Evers wrote: Hi Steve, I want my software be FIPS 140-2 validated, not just experiment with source. The Security Policy document point me to use openssl-fips-1.2.3.tar.gz. Should I remove openssl-0.9.8r.tar.gz? You cannot build the FIPS canister from

[bug] _stprintf() isn't usable in ms/uplink.c, replace with _sntprintf

The studio 2010 compiler fails to process _stprintf due to missing len arg, and the stdc header's confusion over which API it is implementing. The simple fix is to substitute _sntprintf which is unambiguous... line 43 becomes; len = _sntprintf (msg,sizeof(msg)/sizeof(TCHAR),

Re: [openssl.org #2504] Cross Compile MinGW DLLs on Linux

On 4/27/2011 4:09 PM, Roumen Petrov wrote: May be those files are not up to date . Backup them, try make util/libeay.num make util/ssleay.num after ./Configure and compare with saved. These are auto-generated (in do_*.bat mechanics); perhaps they should have really been a build makefile

Re: [openssl.org #2504] Cross Compile MinGW DLLs on Linux

On 4/27/2011 4:09 PM, Roumen Petrov wrote: May be those files are not up to date . Backup them, try make util/libeay.num make util/ssleay.num after ./Configure and compare with saved. These are auto-generated (in do_*.bat mechanics); perhaps they should have really been a build makefile

Re: Client Initiated Renegotiation after 0.9.8l

On 4/13/2011 5:42 PM, Chris Hill wrote: Open SSL dev team, It seems like in releases after OpenSSL 0.9.8l (the ones that contained the fix for cve 2009-3555), client initiated secure/safe renegotiationw was never re-enabled by default, judging by how Apache behaves. Since you are

[openssl.org #2434] Intermittent failure invoking fipslink.pl

The logic of invoking invoking the $fips_premain_dso to determine its hash using perl `commandline` syntax, and immediately asking the local linker to overwrite the binary is fundamentally flawed on win32 and probably aix and others, who cannot overwrite a currently executing file. There is no

Re: New Sponsor for the FIPS Validation

On 1/14/2011 10:15 AM, Steve Marquess wrote: To date the following platforms are included in the validation: Android on ARM VC++ WIN32/x86 Clarification please; in the past the source code build has been validated, with specific platforms chosen for validation testing. Will this

Re: PURIFY flag in md_rand.c and a strongly worded comment

On 6/14/2010 7:59 PM, Nicholas Maniscalco wrote: Is using OpenSSL built with the PURIFY flag considered secure? I ask because I came across this comment, in md_rand.c: #ifndef PURIFY /* purify complains */ /* DO NOT REMOVE THE FOLLOWING CALL TO MD_Update()! */ if

Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)

On 4/27/2010 5:35 AM, Mounir IDRASSI wrote: Hi, I have on purpose only added /Zi to the debug build because it is not always desirable to add symboles to release builds whereas it is always needed for debug ones. No, it's always desirable, and actually irresponsible not to track symbols

Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)

On 4/27/2010 5:35 AM, Mounir IDRASSI wrote: Hi, I have on purpose only added /Zi to the debug build because it is not always desirable to add symboles to release builds whereas it is always needed for debug ones. No, it's always desirable, and actually irresponsible not to track symbols

Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)

On 4/26/2010 1:18 PM, Mounir IDRASSI via RT wrote: Hi, This patch adds the /Zi switch to CFLAG in the debug configuration in order to permit stepping inside OpenSSL code during debug sessions. It applied to the latest snapshots of 1.0.0 and 0.9.8 source trees. It should be in base_cflags,

Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)

On 4/26/2010 1:18 PM, Mounir IDRASSI via RT wrote: Hi, This patch adds the /Zi switch to CFLAG in the debug configuration in order to permit stepping inside OpenSSL code during debug sessions. It applied to the latest snapshots of 1.0.0 and 0.9.8 source trees. It should be in base_cflags,

Re: Flaw in win32 NASM build steps

On 3/22/2010 4:02 PM, Andy Polyakov wrote: The nasmw.exe file no longer exists. The program is now distributed as simply nasm.exe and the build files should be adjusted in 1.0 and 0.9.8 branches to reflect this. ??? The issue was addressed in 0.9.9 and 1.0 a while (like two years) ago.

Re: Flaw in win32 NASM build steps

On 3/22/2010 5:10 PM, Andy Polyakov wrote: The nasmw.exe file no longer exists. The program is now distributed as simply nasm.exe and the build files should be adjusted in 1.0 and 0.9.8 branches to reflect this. ??? The issue was addressed in 0.9.9 and 1.0 a while (like two years) ago.

Flaw in win32 NASM build steps

The nasmw.exe file no longer exists. The program is now distributed as simply nasm.exe and the build files should be adjusted in 1.0 and 0.9.8 branches to reflect this. This will save the user from adding symlinks to this stale program reference.

Windows support baseline [was: Unwanted dependencies to user32.dll]

On 3/16/2010 4:53 PM, Kees Dekker wrote: * I saw a lot of NT4 code. What NT4 code? You must be referring to _WIN32_WINNT macro sometimes set to 0x400. It does not denote NT4-specific code, it denotes that NT4 is required *minimum*. Meaning that it targets *all* Windows versions

Re: FIPS capable with cryptodev/padlock bug or feature?

Peter Fry wrote: I recently discovered that openssl doesn't use cryptodev or padlock when compiled with the fips option (even though the engine was set.. i.e.: oepnssl speed -evp aes-128-cbc -engine padlock). It seems to me that the engines should be used unless FIPS mode has been set. What's

Re: OpenSSL 0.9.8l released

Dr. Stephen Henson wrote: On Sat, Nov 07, 2009, Guenter wrote: Hi Steve, Dr. Stephen Henson schrieb: Oops, I forgot 0.9.8l is just 0.9.8k + the reneg patch and not 0.9.8-stable. hmmm, that is really not what many would expect now; f.e. all folks who reported bugs agaist 0.9.8k will now

Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it

Kyle Hamilton wrote: In addition, Intel has been playing nice and getting its code in the openssl distribution, as a set of patches that were integrated not too long ago. Nobody has submitted such a patch for the Geode to my knowledge (I'm not god of the request tracker, but most mails sent

Clean up no-mdc2 default no-patent cruft?

This patent expired 2 years ago, it seems 1.0.0 is a good time to get this fixed... at least if it remains default-disabled, then the justification should be noted (no longer patented but perhaps some deprecated commentary?) I think the changes are limited to the lines below... README --

Re: Fw: How is OpenSSL affected by changes to Daylight Saving Time (DST) in 2007?

durgaprasad jammula wrote: I have a question. How is OpenSSL affected by changes to Daylight Saving Time (DST) in 2007? And how long ago did you stop beating your wife? (A question with an inherent assumption that it's affected in the first place.) OpenSSL code falls back on the c library

Re: [Patch]: Issues with arch:opt:opt:opt pattern replacement

Gentle ping... is there any desire to implement this sort of a solution? Any feedback on the suggested syntax? I'm happy to forward port this now to trunk for folks to begin experimenting with it, if there is interest. William A. Rowe, Jr. wrote: Patch attached against 0.9.7, out of cycles

[Patch]: Issues with arch:opt:opt:opt pattern replacement

and feedback welcome. Bill William A. Rowe, Jr. wrote: ./Configure platform:cc:cflags:unistd:thread_cflag:sys_id:lflags today sets the remaining 17 flags to defaults - not to {platform}'s original defaults, but far less useful defaults. For an illustration, compare configuring with your

Issues with arch:opt:opt:opt pattern replacement

Rather than perpetually patch Configure, I'm trying to determine if there is a way to substitute just one of the options. E.g., the patterns for linux are fine, but in order to avoid confusing the environment, I'd like to override cc with gcc -m32 or gcc33 and otherwise accept openssl's other opt

Re: Issues with arch:opt:opt:opt pattern replacement

Richard Salz wrote: E.g., the patterns for linux are fine, but in order to avoid confusing the environment, I'd like to override cc with gcc -m32 or gcc33 and otherwise accept openssl's other opt patterns verbatim. something like this, around line 943: my $cc = $ENV{'CC'} ||

Re: Compiler otimization error on Solaris AMD64

Well documented; see bug rt 1281, just tweak -xdepend - because this was already a problem for both sparc and x86, the fact that it's present in 64 bit compilations is no surprise. David Shambroom wrote: The file openssl_0.9.8b/crypto/aes/aes_core.c is based on rijndael-alg-fst.c by Rijnmen,

Re: Any possibility of GPL-based license in the future?

Is it perhaps time for the project maintainers to author the definative Why OpenSSL is not GPL Licensed, and why it will not be (not argumentative diatriabe, just simply stating the facts)? Post this on openssl.org and offer inquiring minds a pointer? This is getting silly when 30 days can't

Re: [openssl.org #1322] Patch to openssl-0.9.8a tree to compile on Win32 with Visual C++ 2005 Express

FWIW, I've posted our short-term fix to openssl-0.9.7i and 0.9.8a at http://www.apache.org/dist/httpd/binaries/win32/patches_applied/ Almost every patch I've seen is painfully twisted, these are the least complex I could come up with that seemed rational. Note; they add the .pdb output I've

Re: [openssl.org #1281] Solaris9: 'make test' failure in evp_test

this failure. We now have confirmation that this fixes problems seen in solaris 9 and 10, multiple cc versions, both x86 and sparc hardware. Please apply :) Bill William A. Rowe, Jr. wrote: Kyle Hamilton wrote: Have you filed a bug with Sun about this issue? No, because the specific loop that failed

Re: [openssl.org #1281] Solaris9: 'make test' failure in evp_test

Glad this licked it [yes I was that guest, forgot to sign my note, sorry.] One thing about -xdepend is that Solaris cc 5.x is unrolling one of our loops incorrectly. If someone wants to simplify, try reducing the complex for (;;) and while () loops to avoid (;;x++, y++) or (;x[c++] +=x;) sorts

Re: [openssl.org #1281] Solaris9: 'make test' failure in evp_test

optimizations are a historical sore point with solaris compilers, appearing to have many artificats from overly agressive optimization. Research -xdepend bugs in the solaris CC release notes, any flavor from the SunStudio 8 through 11. Bill On 2/27/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote

Re: Alternative Interface that doesn't use Sockets?

Apache 2.x mod_ssl (http://httpd.apache.org/) in fact does not use sockets, but creates a brigade of buffers to pass up and down the chain. You may want to compare your implementation ideas to that implementation. Bill Michael B Allen wrote: Hi, I have an idea for a new interface. At least

Re: ts/*.c files

Gisle Vanem wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 14 February 2006 11:26, Gisle Vanem wrote: Some of the new ts/ files are too long for a 8+3 filesystem. a ton of files are too long for 8+3 filesystem in the openssl tarball None of the *.[ch] files. They are all 8+3

Re: servername extension and apache 2.2.0

If you want to submit and have considered by the httpd project, perhaps you ment to submit it there? Nice work b.t.w. Bill Peter Sylvester wrote: Hello, I just have put together the small patch for apache 2.2.0 which allows to use the sernername extension logic in the development snapshot

Re: HPUX PARISC 32 Fatal Makefile Flaw

Andy Polyakov wrote: But without splitting -Wl,-Fl from libssl.a with a space, ??? 'cc -b -Wl,-Fl,libssl.a ...' should be/is translated to 'ld -b -Fl libssl.a ...' by cc. Comma in cc -Wl stands for space in ld line. Yes, that is absolutely correct. However, you are telling cc to pass

HPUX PARISC 32 Fatal Makefile Flaw

Well here's a nice ten-liner that will undo the recent damage to HPUX 32 bit builds using HP's compilers/linkers; + cc -b -Wl,-B,symbolic,+vnocompatwarnings,-z,+h,libssl.sl.0.9.7 -o libssl.sl.0.9.7 -Wl,-Fl,libssl.a -ldld chmod: can't access libssl.sl.0.9.7 WTF is it about? Well, used to link

[Fwd: OpenSSL Patents?]

This bounced first try, but I was not (yet) subscribed, so I'm resending. Appologies if this arrives twice. Original Message Subject: OpenSSL Patents? Date: Tue, 06 Dec 2005 16:26:15 -0600 From: William A. Rowe, Jr. [EMAIL PROTECTED] Reply-To: dev@httpd.apache.org To: dev

Re: [Fwd: OpenSSL Patents?]

Nils Larsch wrote: afaik the included ec algorithms are not tainted by patents but as some countries have braindead patent laws you can never be sure ... Obviously neither the openssl nor apache httpd projects take responsibility for deep patent searches, and should we discover we have

0.9.6e boffed on Win32 ... but easily recoverable

Attached is a trivial patch to allow Win32 to build the OpenSSL dll's. If you want to post it up to contrib, that's fine. Even a non-patch user should be able to follow what to do. Will # The new OpenSSLDie() entry point was undefined in the 0.9.6e release # and win32 dll's will not build