summaryrefslogtreecommitdiff
path: root/crypto/opensslv.h
Commit message (Collapse)AuthorAgeFilesLines
* HEAD is now 1.1.0steve2009-03-311-4/+4
| | | | The 1.0.0 branch is now OpenSSL_1_0_0-stable
* Nothing to see here... move along....steve2009-03-281-4/+4
|
* Reorganize the data used for SSL ciphersuite pattern matching.bodo2007-02-171-1/+1
| | | | | | | | | | This change resolves a number of problems and obviates multiple kludges. A new feature is that you can now say "AES256" or "AES128" (not just "AES", which enables both). In some cases the ciphersuite list generated from a given string is affected by this change. I hope this is just in those cases where the previous behaviour did not make sense.
* I just branched 0.9.8, so HEAD needs to be bumped to 0.9.9-dev.levitte2005-05-181-3/+3
| | | | The 0.9.8 branch is called OpenSSL_0_9_8-stable.
* Make reservations for FIPS code in HEAD branch, so that the moment FIPSappro2004-05-171-0/+4
| | | | comes in we have required macros in place.
* The version of the shared library should, for now, reflect the versionlevitte2002-07-311-1/+1
| | | | | of OpenSSL. Part of PR 181.
* Change the date to XX xxx XXXX in development versions.levitte2002-04-111-1/+1
|
* Modify the main trunk version to 0.9.8-dev.levitte2002-02-131-2/+2
| | | | 0.9.7 now lives in the branch OpenSSL_0_9_7-stable.
* Apply the Tru64 patch from Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu>levitte2001-08-101-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | His comments are: 1) Changes all references for `True64' to be `Tru64', which is the correct spelling for the OS name. 2) Makes `alpha-cc' be the same as `alpha164-cc', and adds an `alphaold-cc' entry that is the same as the previous `alpha-cc'. The reason is that most people these days are using the newer compiler, so it should be the default. 3) Adds a bit of commentary to Configure, regarding the name changes of the OS over the years, so it's not so confusing to people that haven't been with the OS for a while. 4) Adds an `alpha-cc-rpath' target (which is *not* selected automatically by Configure under any circumstance) that builds an RPATH into the shared libraries. This is explained in the comment in Configure. It's very very useful for people that want it, and people that don't want it just shouldn't choose that target. 5) Adds the `-pthread' flag as the best way to get POSIX thread support from the newer compiler. 6) Updates the Makefile targets, so that when the `alpha164-cc', `alpha-cc', or `alpha-cc-rpath' target is what Configure is set to use, it uses a Makefile target that includes the `-msym' option when building the shared library. This is a performance enhancement. 7) Updates `config' so that if it detects you're running version 4 or 5 of the OS, it automatically selects `alpha-cc', but uses `alphaold-cc' for versions 1-3 of the OS. 8) Updates the comment in opensslv.h, fixing both the OS name typo and adding a reference to IRIX 6.x, since the shared library semantics are virtually identical there.
* In version numbers, there is just one "M" nybble.bodo2001-07-101-1/+1
|
* Bump the shared library version (should have been done a while ago).levitte2000-10-131-1/+1
|
* Update the status and version number to 0.9.7-dev.levitte2000-09-241-2/+2
|
* Time to build the release. Bump the version info accordingly.levitte2000-09-241-2/+2
|
* Time to build beta 3. Bump the version numbers accordingly.OpenSSL_0_9_6-beta3levitte2000-09-211-2/+2
|
* A new beta is being released. Change the version numbersOpenSSL_0_9_6-beta2levitte2000-09-171-2/+2
| | | | accordingly.
* Time to release a beta. Change the version numbers and dateslevitte2000-09-111-3/+3
| | | | accordingly.
* Redo and enhance the support for building shared libraries. Currentlylevitte2000-07-211-0/+53
| | | | | | | | | | | | | | | | | | | | | there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
* Tagging has now been done, update to the next possible version (I keeplevitte2000-04-011-2/+2
| | | | a low profile, so we don't get discontinuity in the numbering...)
* Building version 0.9.5alevitte2000-04-011-2/+2
|
* Tagging has been done, update to next probable version...levitte2000-03-231-2/+2
|
* Time for version 0.9.5a beta2levitte2000-03-231-1/+1
| | | | | I know it's earlier than announced. The high amount of problems in beta1 warants this, however.
* Tagging done, we move to the next possible.levitte2000-03-201-2/+2
|
* Change the version text, it's time to release the first beta of 0.9.5a.levitte2000-03-201-4/+4
|
* Change the notation and coding of the version to be able to containlevitte2000-03-191-7/+18
| | | | | | both a patch level and a beta status. IMHO, it also makes more sense to have beta status be part of the development status than to have it be an alternate name for patch levels under special conditions.
* Tagging has been done, time to switch to 0.9.6-dev.levitte2000-02-281-2/+2
|
* Time for a releaselevitte2000-02-281-2/+2
|
* For lack of a better name, this is now called 0.9.5beta3-dev until thelevitte2000-02-271-2/+2
| | | | release.
* Change version string to reflect the release of beta 2.OpenSSL_0_9_5beta2levitte2000-02-271-1/+1
|
* Clarification.bodo2000-02-251-1/+1
|
* Version 0.9.5beta2-dev (so that the next snapshot will notbodo2000-02-241-2/+2
| | | | | | | | | | claim to be 0.9.5beta1). (Are the version number examples correct -- the same numerical code for: * 0.9.3beta2-dev 0x00903002 * 0.9.3beta2 0x00903002 ?)
* 0.9.5beta1OpenSSL_0_9_5beta1levitte2000-02-241-2/+2
|
* Bump after tarball rolling.rse1999-08-091-2/+2
| | | | Friends, feel free to start again hacking for 0.9.5... ;)
* Bump version to 0.9.4OpenSSL_0_9_4rse1999-08-091-2/+3
|
* And carry on with development...ben1999-05-291-2/+2
|
* Oops!OpenSSL_0_9_3aben1999-05-291-1/+1
|
* Prepare to release 0.9.3aben1999-05-291-3/+3
|
* Move on to 0.9.4.ben1999-05-241-2/+2
|
* Here we go: prepare to roll 0.9.3.OpenSSL_0_9_3ben1999-05-241-2/+2
|
* Move to beta 3.ben1999-05-231-2/+2
|
* Prepare for final(?) beta.OpenSSL_0_9_3beta2ben1999-05-231-1/+1
|
* On seconds thoughts, the version number shoud _never_ decrease.ben1999-05-201-7/+9
|
* Revert.ben1999-05-201-2/+2
|
* Prepare for a beta release.OpenSSL_0_9_3beta1ben1999-05-201-2/+2
|
* Note that the numbering scheme used to be different.bodo1999-05-191-0/+1
|
* Switch to new version numbering scheme.ben1999-05-191-2/+11
|
* Protect applications from failing to compile when theyrse1999-05-181-0/+5
| | | | try to directly include opensslv.h.
* pre-0.9.3 development version.ulf1999-04-011-2/+2
|
* Fix security hole.ben1999-03-221-0/+3
View Lorry Controller Status