#
296341 |
|
03-Mar-2016 |
delphij |
Fix multiple OpenSSL vulnerabilities.
Security: FreeBSD-SA-16:12.openssl Approved by: so
|
#
272461 |
|
02-Oct-2014 |
gjb |
Copy stable/10@r272459 to releng/10.1 as part of the 10.1-RELEASE process.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
269686 |
|
07-Aug-2014 |
jkim |
MFC: r269682
Merge OpenSSL 1.0.1i.
|
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
246772 |
|
13-Feb-2013 |
jkim |
Merge OpenSSL 1.0.1e.
Approved by: secteam (simon), benl (silence)
|
#
238405 |
|
12-Jul-2012 |
jkim |
Merge OpenSSL 1.0.1c.
Approved by: benl (maintainer)
|
#
237657 |
|
27-Jun-2012 |
jkim |
Merge OpenSSL 0.9.8x.
Reviewed by: stas Approved by: benl (maintainer) MFC after: 3 days
|
#
215697 |
|
22-Nov-2010 |
simon |
Merge OpenSSL 0.9.8p into head.
Security: CVE-2010-3864 Security: http://www.openssl.org/news/secadv_20101116.txt
|
#
205128 |
|
13-Mar-2010 |
simon |
Merge OpenSSL 0.9.8m into head.
This also "reverts" some FreeBSD local changes so we should now be back to using entirely stock OpenSSL. The local changes were simple $FreeBSD$ lines additions, which were required in the CVS days, and the patch for FreeBSD-SA-09:15.ssl which has been superseded with OpenSSL 0.9.8m's RFC5746 'TLS renegotiation extension' support.
MFC after: 3 weeks
|
#
194206 |
|
14-Jun-2009 |
simon |
Merge OpenSSL 0.9.8k into head.
Approved by: re
|
#
162914 |
|
01-Oct-2006 |
simon |
Resolve conflicts after import of OpenSSL 0.9.8d.
|
#
160817 |
|
29-Jul-2006 |
simon |
Resolve conflicts after import of OpenSSL 0.9.8b.
|
#
142428 |
|
25-Feb-2005 |
nectar |
Resolve conflicts after import of OpenSSL 0.9.7e.
|
#
120635 |
|
01-Oct-2003 |
nectar |
Merge conflicts after import of OpenSSL 0.9.7c.
|
#
112446 |
|
20-Mar-2003 |
jedgar |
Merge conflicts
|
#
111150 |
|
19-Feb-2003 |
nectar |
Resolve conflicts after import of OpenSSL 0.9.7a.
|
#
110007 |
|
28-Jan-2003 |
markm |
Merge conflicts. This is cunning doublespeak for "use vendor code".
|
#
100943 |
|
30-Jul-2002 |
nectar |
Resolve conflicts after import of OpenSSL 0.9.6e.
|
#
89840 |
|
27-Jan-2002 |
kris |
Resolve conflicts.
|
#
76870 |
|
20-May-2001 |
kris |
Resolve conflicts
|
#
72616 |
|
18-Feb-2001 |
kris |
Resolve conflicts
|
#
68654 |
|
13-Nov-2000 |
kris |
Resolve conflicts, and garbage collect some local changes that are no longer required
|
#
63249 |
|
16-Jul-2000 |
peter |
Forced commit. This is to try and help folks that used the international crypto repo and have slightly different files but with the same version. cvsup in 'checkout mode' has no trouble with this, but cvs can get really silly about it.
|
#
57510 |
|
26-Feb-2000 |
peter |
At great personal risk (to my already fragile sanity), reorganize the rsa stubs for libcrypto. libcrypto.so now uses dlopen() to implement the backends for either the native or rsaref implemented RSA code. This involves: - unifying the libcrypto and openssl(1) source so there is no #ifdef RSAref variations. - using weak symbols and dlopen()/dlsym() routines to access the rsa method vectors.
Releases will enable the user to choose International, US (rsaref) or no RSA code at install time. 'make world' will DTRT depending on whether you have the international or US source. For US users, you must either install rsaref (the port or package) or (if you don't fear RSA Inc) use the (superior) International rsa_eay.c code.
This has been discussed at great length by the affected folks and even we have a great deal of confusion. This is a checkpoint so we can tune the results. This works for me in all permutations I can think of and should result in a CD/ftp 'release' just about doing the right thing now.
|
#
55100 |
|
25-Dec-1999 |
kris |
This commit was generated by cvs2svn to compensate for changes in r55099, which included commits to RCS files with non-trunk default branches.
|
#
55099 |
|
25-Dec-1999 |
kris |
Initial import of OpenSSL v0.9.4
|