Re: [openssl-dev] Submitting new bugs to rt via mail broken?
On Mon, Feb 23, 2015 at 11:53:17AM +0100, Rainer Jung wrote: Am 10.02.2015 um 21:30 schrieb Matt Caswell: On 10/02/15 19:23, Rainer Jung wrote: Hello everyone, I sent a mail to r...@openssl.org 3 days ago, subject OpenSSL 1.0.2 make test bus error in evp_test (Solaris 10 Sparc, sun4u). The mail didn't create a new ticket in RT, nor was it forwarded to the dev list. Should I resend or simply be more patient? Email to rt is manually moderated by Lutz. Sometimes it can take a few days to come through. Very occasionally a genuine email gets lost within the swamp of spam. I would be a little more patient, but if it doesn't arrive in a couple more days then try again. I tried again on Feb 14, about a week ago. Still nothing shows up in RT or on mailing lists. Other mails on the dev list also indicate problems with stalled RT communication. Please don't send your original submissions as replies to other emails. It just was sorted into the thread and I hence missed it. Sorry, Lutz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [PATCH] Advance to the next state variant when reusing messages
On Mon, Nov 10, 2014, Piotr Sikora wrote: (for some reason it was never received by rt@, so resending here) Slipped through the moderation queue, sorry. It is in RT now. Best regards, Lutz -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL mail server issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Due to a misunderstanding within the OpenSSL team we ran into trouble with our mail and mailing service still hosted at the old server (hopefully I will be able to complete the migration to the new server over the Christmas break). Caused by a software upgrade on Monday, Dec 2, 2013 around noon GMT the following problems occured: 1 mail was not received due to software failure (which is ok as mail is queued at the sender) 2 a malfunction of the majordomo mailing list software lost mails received (which is not ok as these mails seem to be lost permanently). As soon as issue 2 was noted the mail server was shut down again to prevent further loss of mails. As a consequence we seem to have lost mailing list contributions between Monday noon GMT and Tuesday morning GMT. If you have made any submissions that did not yet make it to the lists, please resend them. Most issues are fixed now except for minor effects (I have seen at least one mail passing throught the moderation queue that only reached the list truncated. Sorry for any inconvenience caused, Lutz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQCVAwUBUp7qUniZOxScWKZtAQJmegP/ax8LfFbPsqg3JKDVQ4zokNBQcCg9v6Tg Wy82nqeVDK+14SUgsDJcGDRiVkFYcMHoUANPSvfyprbt/sdbEFaF+1VpsA1Zlzxr f4UM7TkXUhh+7be5wMorG1eQNHs8afQbvFjQ9tMxk84ESxNQ7FmAqAain4pVw7Bk obNOqEy+8as= =+QSD -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL server downtime
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! The new server currently hosting the www, git, rt, ftp, and cvs services is going to be moved within the installation of our hoster. As a consequence, the system will be assigned a new IP address. Old: 178.16.220.54 New: 185.9.166.106 The move is planned to happen around 12.30 UTC on Sunday, 17 Mar 2013. Users are expected to see a short outage of the service. An additional delay may be caused by the old IP address being cached in the DNS. Best regards, Lutz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBUUNJd3iZOxScWKZtAQJlvwQAqZ6o8X70R5gElvX8929c5y+TtU7ViHr3 ClzteUdISun5zK1wCIhewCBEz92s8kCu0RtNk6t6D7g+LNOlAd9T2HO+wB0+WvC1 HMfTHJg3vNW5PgVaEzVEm69Nk4r3zfuXoginuQLHm3qIHopzrQMEy1DWxRD/Aysu AfrtmWYs74A= =TwV7 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2992] [PATCH] Fix POD errors to stop make install_docs dying with pod2man 2.5.0+
Applied. Thanks, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: access to git repository from behind a proxy
On 02/07/2013 03:35 PM, Vladimir Kotal wrote: Hi all, I am trying to follow the steps for cloning the git repository found on http://www.openssl.org/source/repos.html from behind a proxy. The proxy does not allow connections to the git port 9418. I tried http/https which both fail: fatal: https://git.openssl.org/openssl.git/info/refs not found: did you run git update-server-info on the server? which is basically saying there is no repository on the remote end. SSH access is mentioned on the page but it fails too: Cloning into openssl... The authenticity of host 'git.openssl.org (178.16.220.54)' can't be established. RSA key fingerprint is 59:c5:9c:b9:94:39:59:b6:da:59:3b:9d:22:3b:39:9d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'git.openssl.org,178.16.220.54' (RSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly Would it be possible to configure the git repos on git.openssl.org to allow http/https just like on github.com ? A mirror allowing all of githubs protocols is available at github: https://github.com/openssl/openssl I have also updated the Source-Repository page to reflect this fact :-) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL infrastructure migration
Hi! As you will already have noted, the OpenSSL project is currently moving its infrastructure to a new server. This migration is combined with a change and/or upgrade of the tools (CVS - GIT, RT 3.x - 4.x, ...) so we have decided to set up the new server first and to perform a step by step migration. Most of the porting work is now done and I will now start to redirect the DNS entries (one at a time) such that the new services will be enabled. Current status is: * CVS has been retired and is now replaced by git. The last CVS commit was in December. The git repository is available for cloning via git clone git://git.openssl.org/openssl.git and for browsing via http://git.openssl.org/ or https://git.openssl.org/ All commits to the source code in 2013 have already been made using git and the commit mails in the respective new format have been sent via the already existing openssl-cvs mailing list. For obvious reasons we encourage contributors to provide patch and extension proposals using git format... * RT has been upgrade from an outdated version of the 3.x series to 4.0 and is now (again) available via http://rt.openssl.org/ and https://rt.openssl.org/ with the guest account being guest with password guest like before. The other services (web, ftp, mail) are still provided by the old server but will also be migrated soon. I will not update the old web pages to reflect the new setup as I do not intend to keep this state for long. Best regards on behalf of the OpenSSL team, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL infrastructure migration
On 01/15/2013 12:50 PM, Lutz Jaenicke wrote: Hi! As you will already have noted, the OpenSSL project is currently moving its infrastructure to a new server. This migration is combined with a change and/or upgrade of the tools (CVS - GIT, RT 3.x - 4.x, ...) so we have decided to set up the new server first and to perform a step by step migration. Most of the porting work is now done and I will now start to redirect the DNS entries (one at a time) such that the new services will be enabled. Current status is: * CVS has been retired and is now replaced by git. The last CVS commit was in December. The git repository is available for cloning via git clone git://git.openssl.org/openssl.git and for browsing via http://git.openssl.org/ or https://git.openssl.org/ All commits to the source code in 2013 have already been made using git and the commit mails in the respective new format have been sent via the already existing openssl-cvs mailing list. For obvious reasons we encourage contributors to provide patch and extension proposals using git format... * RT has been upgrade from an outdated version of the 3.x series to 4.0 and is now (again) available via http://rt.openssl.org/ and https://rt.openssl.org/ with the guest account being guest with password guest like before. The other services (web, ftp, mail) are still provided by the old server but will also be migrated soon. I will not update the old web pages to reflect the new setup as I do not intend to keep this state for long. In the meantime I have also changed the DNS entries for www.openssl.org, ftp.openssl.org, and rsync.openssl.org have been modified to point to the new server. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL infrastructure migration
On 01/15/2013 12:50 PM, Lutz Jaenicke wrote: Hi! As you will already have noted, the OpenSSL project is currently moving its infrastructure to a new server. This migration is combined with a change and/or upgrade of the tools (CVS - GIT, RT 3.x - 4.x, ...) so we have decided to set up the new server first and to perform a step by step migration. Most of the porting work is now done and I will now start to redirect the DNS entries (one at a time) such that the new services will be enabled. Current status is: * CVS has been retired and is now replaced by git. The last CVS commit was in December. The git repository is available for cloning via git clone git://git.openssl.org/openssl.git and for browsing via http://git.openssl.org/ or https://git.openssl.org/ All commits to the source code in 2013 have already been made using git and the commit mails in the respective new format have been sent via the already existing openssl-cvs mailing list. For obvious reasons we encourage contributors to provide patch and extension proposals using git format... * RT has been upgrade from an outdated version of the 3.x series to 4.0 and is now (again) available via http://rt.openssl.org/ and https://rt.openssl.org/ with the guest account being guest with password guest like before. The other services (web, ftp, mail) are still provided by the old server but will also be migrated soon. I will not update the old web pages to reflect the new setup as I do not intend to keep this state for long. In the meantime I have also changed the DNS entries for www.openssl.org, ftp.openssl.org, and rsync.openssl.org have been modified to point to the new server. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Committing to openSSL - maximum fragment length
On 01/12/2013 01:26 PM, Attila Gulyas wrote: Hi, I have been working on implementing Maximm fragmentation length extension (RFC3546, obsoleted by RFC6066) and I'd like to commit my work so that it'd be available in later editions of openssl. How may I do that? (I've been looking for an SVN access, or something like that.) Hi Attila, we provide a public (read-only) access to our git repository so that you can prepare your contribution as a patch against our code base: git clone git://git.openssl.org/openssl.git Please send your contributions the request tracker via r...@openssl.org. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2952] Testing new RT instance
This is a test of the upgraded RT for openssl.org Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL RT instance migration
Hi, in the process of upgrading and migrating our server infrastructure I have just put the updated Request Tracker into operation. The request tracker stays reachable via r...@openssl.org (or the alias openssl-b...@openssl.org). While the migration is still in progress, the web interface is temporarily available via http[s]://rt.openssl.net/ (please note the .net at the end). Once we have finished updating our infrastructure, the server will move back to openssl.org. Hint: the certificate of the webserver is the openssl.org one so please be prepared for a warning :-) If you are experiencing any problems, please report. Thank you very much for your patience, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
openssl.org web site certificate renewed
Hi! I have just installed a new 3 year wildcard *.openssl.org certificate to our web site. Thanks to GlobalSign for the new donation. The migration should work more or less unnoted for the users. If you experience any problems please drop me a message. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Is RT not accepting patches?
On 04/11/2011 11:10 PM, Tim Jackson wrote: Hi, I sent several patches to openssl-b...@openssl.org a few hours ago, but I haven't seen them get forwarded to this list and don't see them at http://rt.openssl.org/NoAuth/Buglist.html. Is this expected? Does openssl-bugs still work, or do all patches have to go through r...@openssl.org? I don't mind resending, but I didn't want to clog up the patch submission system unnecessarily. openssl-bugs and rt are synonyms. Due to the unavoidable amount of SPAM sent to these addresses moderation has to take place resulting in some delay. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL server failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! unfortunately the OpenSSL project has been hit by a hardware defect (hard disk and power supply). The project hence had to be migrated to a different server using a later version of the operating system and tools. Services are currently being restored: * source code repositories have not been affected(!) * mailing list services should now be up and running again, messages sent between Sunday evening and Tuesday afternoon that have not yet made it to the list are most likely lost. * RT still seems to have some issues. We apologize for any inconvenience. Many thanks to Ralf S. Engelschall who is currently very busy on restoring the services. Best regards, Lutz (on behalf of the team) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBTVFgH3iZOxScWKZtAQLM1QP/bTl9bn2cXxikm07AoVJhLv2jaZEXhdqJ WkBYh8CTaB/FH8FK7K6NntIeyqLK/LjTolU1qpyDxeTRWfxQk/Eiv3Oy6qajJ6tX tHWrwsKlC1mK07BmzNJnabR/YV1BIcAoCA3Y9oK/0Z4+oB3UjI/ehtnK23N9sgKn EY3MqVk/T1Y= =oC9H -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How can I upload that .chm file?
Harold S. Henry wrote: Thanks, Kyle. The problem, as identified in the delivery failure message, is that openssl.org's mail server has a fixed message-size limit that is exceeded by the size of the attachment. Sorry to be unclear. Your contribution has been filed under #2342... but the mail server seems to have eaten RT's mail to the list :-) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How can I upload that .chm file?
Kenneth Robinette wrote: Lutz How does one get access to the contributed .chm file? I looked on the OpenSSL site and cannot see any reference to it? On the bottom of the descriptive test, right hand side, there should be a small reference to OpenSSL.zip. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Version control
Am 28.05.2010 23:08, schrieb David Woodhouse: On Fri, 2010-05-28 at 10:14 +0200, Lutz Jaenicke wrote: The state of the test-repository is a bit old (approx one year) but you may have a look into git://login.openssl.org/openssl http://www.openssl.org/gitweb.cgi/ When the initial test migrations were performed (2 years ago) I used cvs2svn-2.1.1 with some setup in cvs2svn-git.options. Hm, OK. I'll try that again then. Since then Geoff Thorpe also worked a bit on some automatic way to keep the test repo in sync with the CVS repo but all of this is on hold until the team has come to a final decision... What's to decide? Are there any plans being seriously proposed other than 1) Stay in the 20th century with CVS as we are now. 2) Update to git. Surely nobody's suggesting svn/bzr/hg/arch or any of the other artifacts of the one-version-control-system-per-child craze Some of the members of the team do work for google. To my best understanding google is internally using mercurial so this discussion is actually not concluded. Hence the project will stay in the 20th century until a new version control system is agreed upon. I would kindly suggest to not open a discussion about the merits and advantages of the different version control systems on this list Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Version control
Am 27.05.2010 18:48, schrieb David Woodhouse:
On Thu, 2010-05-27 at 17:51 +0200, Lutz Jaenicke wrote:
David Woodhouse wrote:
On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote:
Those [i_a] bits are my markers in our local code base so I know which
edits
are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know
there are smarter systems around, but I've been 'tracking' OpenSSL for
almost a decade and tools available to me haven't always been smart enough
to ensure I didn't lose local edits across upgrades. And drilling down the
RCS database for every edit isn't fun nor fast like that. So marking has
become a habit by now. Often accompanied with a short text about the 'why'
or related info. Sorry, wasn't meant to be bothersome to you.
None of the existing CVS-git import tools handle the OpenSSL repository
correctly -- they all do strange things on branches. But for HEAD, they
should work OK.
So far we have not seen technical problems when last tested.
That's interesting. What tool were you testing? I've had issues with
both cvs2git and git-cvsimport.
My normal reaction in dealing with _any_ project which uses a legacy
version control system (cvs,svn,hg,bzr,etc) is to mirror it into git so
that I can deal with it sensibly. OpenSSL has so far resisted my
efforts, which is one of the reason I find it a PITA to deal with.
The state of the test-repository is a bit old (approx one year) but you
may have a look into
git://login.openssl.org/openssl
http://www.openssl.org/gitweb.cgi/
When the initial test migrations were performed (2 years ago) I used
cvs2svn-2.1.1
with some setup in cvs2svn-git.options. Since then Geoff Thorpe also
worked a bit on some automatic way to keep the test repo in sync with
the CVS repo but all of this is on hold until the team has come to a
final decision...
Best regards,
Lutz
# (Be in -*- mode: python; coding: utf-8 -*- mode.)
# As a partial check that the example options file is functional, we
# use it as the basis for this test. We only need to overwrite the
# output option to get the output repository in the location expected
# by the test infrastructure.
execfile('cvs2svn-example.options')
from cvs2svn_lib.fulltext_revision_recorder \
import SimpleFulltextRevisionRecorderAdapter
from cvs2svn_lib.git_revision_recorder import GitRevisionRecorder
from cvs2svn_lib.git_output_option import GitOutputOption
ctx.trunk_only = False
ctx.cross_project_commits = False
ctx.cross_branch_commits = False
ctx.username = 'cvs2svn'
# CVS uses unix login names as author names whereas git requires
# author names to be of the form foo bar. The default is to set
# the git author to cvsauthor cvsauthor. author_transforms can be
# used to map cvsauthor names (e.g., jrandom) to a true name and
# email address (e.g., J. Random jran...@example.com for the
# example shown). All values should be either 16-bit strings or 8-bit
# strings in the utf-8 encoding.
author_transforms={
'jaenicke' : (u'Lutz Jänicke', 'jaeni...@openssl.org'),
'ben' : ('Ben Laurie', 'b...@openssl.org'),
'levitte' : ('Richard Levitte', 'levi...@openssl.org'),
'bodo' : (u'Bodo Möller', 'b...@openssl.org'),
'ulf' : (u'Ulf Möller', 'u...@openssl.org'),
'steve' : ('Dr. Stephen Henson', 'st...@openssl.org'),
'geoff' : ('Geoff Thorpe', 'ge...@openssl.org'),
'appro' : ('Andy Polyakov', 'ap...@openssl.org'),
'nils' : ('Nils Larsch', 'n...@openssl.org'),
'rse' : ('Ralf S. Engelschall', 'r...@openssl.org'),
'mark': ('Mark J. Cox', 'm...@openssl.org'),
'holger': ('Holger Reif', 'hol...@openssl.org'),
'paul' : ('Paul C. Sutton', 'p...@openssl.org'),
}
# How to convert author names, log messages, and filenames to unicode.
# The first argument to CVSTextDecoder is a list of encoders that are
# tried in order in 'strict' mode until one of them succeeds. If none
# of those succeeds, then fallback_encoder is used in lossy 'replace'
# mode (if it is specified). Setting a fallback encoder ensures that
# the encoder always succeeds, but it can cause information loss.
ctx.cvs_author_decoder = CVSTextDecoder(
[
'latin1',
'utf8',
'ascii',
],
#fallback_encoding='ascii'
)
ctx.cvs_log_decoder = CVSTextDecoder(
[
'latin1',
'utf8',
'ascii',
],
#fallback_encoding='ascii'
)
ctx.output_option = GitOutputOption(
'cvs2svn-tmp/git-dump.dat',
author_transforms=author_transforms,
)
ctx.revision_recorder = SimpleFulltextRevisionRecorderAdapter(
RCSRevisionReader('co'),
GitRevisionRecorder('cvs2svn-tmp/git-blob.dat'),
)
ctx.revision_excluder = NullRevisionExcluder()
ctx.revision_reader = None
run_options.clear_projects()
run_options.add_project(
r'/home/ljaenicke/opensource/openssl/openssl',
symbol_transforms=[
# See cvs2svn-example.options for more
Re: Version control
David Woodhouse wrote: On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote: Those [i_a] bits are my markers in our local code base so I know which edits are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know there are smarter systems around, but I've been 'tracking' OpenSSL for almost a decade and tools available to me haven't always been smart enough to ensure I didn't lose local edits across upgrades. And drilling down the RCS database for every edit isn't fun nor fast like that. So marking has become a habit by now. Often accompanied with a short text about the 'why' or related info. Sorry, wasn't meant to be bothersome to you. None of the existing CVS-git import tools handle the OpenSSL repository correctly -- they all do strange things on branches. But for HEAD, they should work OK. So far we have not seen technical problems when last tested. I'd be very happy to work on fixing that, if there's a real prospect of OpenSSL actually changing over to using such a git repository once it exists. I think that would make life a _lot_ easier for anyone working on OpenSSL. Internal discussion about which version control system to use in the future have not yet been completed. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2191] openSSL-0.9.8m make failure
From: Michael Wodei wo...@us.ibm.com Date: Wed, 10 Mar 2010 04:33:24 -0700 You can withdraw this one, I found the issue Mike Wodei __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL server problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! In the past few days we had some problems with the hardware of the OpenSSL server providing the public services (web, mail, etc). We are now closely monitoring the system and preparing to migrate to another server if necessary. Thank you very much for your patience. Best regards, Lutz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBS5Y9+XiZOxScWKZtAQL7RwP/R+FK3C8MCUDFDYADupddZS01Qx1yBAEf 4G5gdT6N9Hhr1F9LCDRk0liD7E9kERnD/0pYLYH0sV4B9FAWq5JuaekwwrnoSCqu tiJ/y7py/mPKHFA9vPx+/4GyC0AlnOTUcNrUnahXi7lQp5sRq78/Uk2w6RXZX2iY UfpFnI+yqL0= =2kO7 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Test of disabled renegotiation in 0.9.8l
Boyle Owen wrote: PPS: Although I have subscribed to this list, I am not getting the mails (I have to keep checking the archives). Is there anyone who can check out my account? Hmm. If memory serves me right there was a subscribe message sent to the list instead of the mailing list manager (which I then moderated away)... Please try again, we do have some handy form on the web page. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH 00/14] Patches from the ocf-linux and uClinux-dist projects
David McCullough wrote: Jivin Kyle Hamilton lays it down ... Please mail these each as attachments to r...@openssl.org. This will ensure that each gets entered into a trackable state, and also ensures that the formatting for the patch files stays consistent. No problems, I wasn't sure if I should do that or not, so I opted to not spam two lists ;-) It seems the mailing list ate 3 of the patches (#2 #6 and #10), hopefully RT will deal with them, The contents of some of your patches triggered the SPAM protection and were sent to the moderation queue for manual approval. So they only showed up with a delay caused by the moderator not being online 24/7 :-) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1786] 0.9.9 HEAD: X509_POLICY_DATA/NODE function implementations missing - fix included
Closing as resolved. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: I hope the reports that I sent to -bugs are useful...
Kyle Hamilton wrote: I hope the test reports I sent to -bugs are useful. I'm on a Mac OSX 10.5.6 machine, Intel-based, and I ran tests in both 32 and 64 bit modes, both without and with the optional features. I do not have gmp installed, nor zlib, so I cannot vouch for their usability; I did not test krb5, and I also did not test the shared option. Hi Kyle, thank you very much for reports, they are currently sitting in the moderation queue. I would kindly ask you and other testers to either * send success messages to the list with just the platform mentioned * send failures to openssl-bugs (or rt which is an alias) with a suitable subject line exposing the platform and type of problem Re: OpenSSL 1.0.0 beta1 released is not too useful as it will end up in many open tickets all having the same non-informative subject. Thank you very much, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: I hope the reports that I sent to -bugs are useful...
Kyle Hamilton wrote: On Wed, Apr 1, 2009 at 4:55 AM, Lutz Jaenicke l...@lutz-jaenicke.de wrote: Hi Kyle, thank you very much for reports, they are currently sitting in the moderation queue. I would kindly ask you and other testers to either * send success messages to the list with just the platform mentioned * send failures to openssl-bugs (or rt which is an alias) with a suitable subject line exposing the platform and type of problem Re: OpenSSL 1.0.0 beta1 released is not too useful as it will end up in many open tickets all having the same non-informative subject. Thank you very much, Lutz Hi Lutz, The problem with 'just the platform mentioned' is that there are two separate types of platforms on OSX -- 32 bit and 64 bit. I tested the default configuration on each. In addition, I also tested the experimental-jpake, enable-rfc3779, experimental-store, and basically all the other options I had available, in separate tests (both 32- and 64-bit). I'd figured that you'd have the ability to parse the configuration lines so that you could identify the options in use, the platform, and any combination which resulted in a test failure -- and that more information would be easier to diagnose problems with than less. Which list should I send success reports to? The body will need to include the compiler, the Configure options, and platform at the very least; that's a bit too much to fit into an appropriate Subject. (Or am I taking the concept of a proper, comprehensive test matrix too seriously for the OpenSSL team's liking?) Probably you are not around long enough for the last (0.9.8) release :-) In the past we tended to have the success reports sent to openssl-dev. The problem with the success reports is that they are actually invalidated with every new iteration so keeping those in the request tracker is not the correct way. I am considering on how to collect the success information which is probably best handled with a yes or no (or the yes: betaX) in a spreadsheet. Failures have to be looked into one by one and hence should go into separate tickets in the request tracker. Best regards, Lutz I am considering how to collet __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Can not mail to r...@openssl.org.
Jurko Gospodnetić wrote: Hi all. Just wandering whether there is something I am missing about posting bug reports/patches to 'r...@openssl.org'. I send a report there three days ago and got neither any confirmation nor did the report get forwarded to the development list. I resent the same report yesterday and still nothing. I sent the report from the same e-mail address I am posting this from. Is there some registration I'm missing in order to be able to send in patches using 'regular channels' as suggested on 'http://www.openssl.org/support/rt.html'? Or is perhaps my subject line supposed to be formatted in a specific way? Or is it just that the list is moderated and no moderators have yet gotten to looking over my report? It is moderated and I just did not find time to work through the moderation queue from Friday evening till now. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1787] [PATCH] speed -multi buffered output fix
Thanks, patch applied. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1761] [PATCH] AWOL openssl s_client eating CPU time.
Patch applied. Thanks, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1764] openssl-0.9.8i random generator bug
[EMAIL PROTECTED] - Tue Oct 21 14:23:50 2008]:
Hello rt,
During stress testing my project, suddenly got crash inside openssl
openssl version - openssl-0.9.8i
compiler - Microsoft Visual Studio 2008 Professional Edition (C++
project)
project - x64 debug compilation
OS - Microsoft Windows XP x64 Edition Service Pack 2
usage example:
__inline void Rand(unsigned char* pBuf, uintptr_t nSize)
{
RAND_pseudo_bytes(pBuf,int(nSize));
}
__inline uintptr_t Rand(void)
{
uintptr_t nRet;
Rand(reinterpret_castunsigned
char*(nRet),sizeof(uintptr_t));
return nRet;
}
uintptr_t = Rand();
stress test:
my code executing Rand() repeately in two threads with
100% loading of Dual Core CPU, in 100k-300k calls application
crashes. no need to wait long :)
crash:
0xc005 (ACCESS_VIOLATION)
sha1_block_data_order d:\libraryes\openssl-
0.9.8i\crypto\sha\sha_locl.h (259)
where is wrong:
ssleay_rand_bytes d:\libraryes\openssl-
0.9.8i\crypto\rand\md_rand.c (474)
crypto\rand\md_rand.c line 470:
k=(st_idx+MD_DIGEST_LENGTH/2)-st_num; --- something wrong
around this line
with this data I'm getting crash:
st_idx = 1032
st_num = 1023
k=(st_idx+MD_DIGEST_LENGTH/2)-st_num; // k == 19
// MD_DIGEST_LENGTH/2-k == -9
MD_Update(m,(state[st_idx]),MD_DIGEST_LENGTH/2-k); // with -9 it
will crash
I'm getting 100% crashes at each stress test. :(
Hmm, that is odd. STATE_SIZE is 1024, so there must not be st_idx
with a value larger than 1023. Upon call st_idx is set from state_index.
As your application is using threads: have you made sure that proper
locking functions are activated? A failure to properly lock the threads
while updating st_idx and friends would explain a failure like this.
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1703] Bug report for DTLS
David Woodhouse wrote: On Mon, 2008-10-13 at 09:01 +0200, Lutz Jaenicke via RT wrote: Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling is not present in HEAD (0.9.9). That makes sense. I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the pre-RFC version of DTLS was considered to be an OpenSSL-specific thing that would quickly die out as people upgraded to 0.9.8f and beyond? Now we've observed that there are servers in the wild which implement that old OpenSSL-specific version of the protocol, but which we'd like to be compatible with. If I can actually get that working in HEAD, would a patch to support it be acceptable? I had a deeper look into the mailing list archive and I did not find any explicit statement on why this was handed differently in 0.9.8 and in HEAD. Finally we would of course prefer to move people to update to an RFC compliant version, so I guess the pre-RFC support should be configurable somehow. Andy, what do you think? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1752] DTLS drops incoming packets when they are reordered.
From answer only sent to mailing list: Yeah, it looks right. I haven't yet got it working with my test case, because I need to use DTLS1_BAD_VER and there are other parts missing from HEAD for that, on top of my patch in #1751 -- but I agree with your assessment that it shouldn't be needed any longer. Thanks, fix applied. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1703] Bug report for DTLS
[jaenicke - Fri Oct 10 12:42:51 2008]: I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I am not very familiar with the DTLS implementation so hopefully I did not break it. Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling is not present in HEAD (0.9.9). Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1703] Bug report for DTLS
I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I am not very familiar with the DTLS implementation so hopefully I did not break it. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1752] DTLS drops incoming packets when they are reordered.
[EMAIL PROTECTED] - Tue Oct 07 10:57:04 2008]:
This patch to the 0.9.8 branch fixes two bugs with misordered incoming
packets in DTLS, which are reported as RT #1752.
Could you comment on the 0.9.9-dev branch as well?
The patch to d1_pkt.c applies fine. The length object is gone from the
code so it should not be needed any longer.
Best regards,
Lutz
Firstly, the bitmap we use for replay protection was ending up with zero
length, so a _single_ pair of packets getting switched around would
cause one of them to be 'dropped'.
Secondly, it wasn't even _dropping_ the offending packets, in the
non-blocking case. It was just returning garbage instead.
--- ssl/d1_lib.c~ 2008-10-02 06:43:47.0 +0100
+++ ssl/d1_lib.c 2008-10-05 21:31:38.0 +0100
@@ -106,6 +106,7 @@ int dtls1_new(SSL *s)
pq_64bit_init((d1-bitmap.map));
pq_64bit_init((d1-bitmap.max_seq_num));
+ d1-next_bitmap.length = d1-bitmap.length;
pq_64bit_init((d1-next_bitmap.map));
pq_64bit_init((d1-next_bitmap.max_seq_num));
--- ssl/d1_pkt.c~ 2008-10-02 06:43:47.0 +0100
+++ ssl/d1_pkt.c 2008-10-05 21:44:54.0 +0100
@@ -597,6 +597,7 @@ again:
/* check whether this is a repeat, or aged record */
if ( ! dtls1_record_replay_check(s, bitmap, (rr-seq_num)))
{
+ rr-length = 0;
s-packet_length=0; /* dump this record */
goto again; /* get another record */
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1752] DTLS drops incoming packets when they are reordered.
David Woodhouse via RT wrote: (Was waiting for the RT to autoreply with a number before I followed up, but it doesn't seem to have arrived after half an hour, so I'll send anyway. Hopefully the References: header will associate this with the previous mail anyway...) Mailings to rt are moderated. The requested association was thus performed by the moderation mechanism :-) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1757] Compile crash on IA64 due to crypto/sha/Makefile problem
Thanks, I have applied the respective patch to the 0.9.7, 0.9.8 and 0.9.9 branches, see http://cvs.openssl.org/rlog?f=openssl/crypto/sha/Makefile for commits 17496 to 17498. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL Web Server Certificate renewed
Hi! I have just installed a new (2048bit) certificate and key to the OpenSSL Project webserver. It is a wildcard certifcate for *.openssl.org catching both www.openssl.org and rt.openssl.org. Many thanks go to Steve Roylance from Globalsign for donating a 3 year wildcard SSL certificate!! Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1727] No License error getting
It seems you do not have enough licenses for your C compiler which is thus locking up. Sincere regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1728] Root Certificate Program
The OpenSSL project does not have a root CA program and has decided to not supply root CA certificates with the toolkit. Please checkout the FAQ: How can I set up a bundle of commercial root CA certificates? http://www.openssl.org/support/faq.html#USER16 Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: non-blocking SSL_read() API problem
Thor Lancelot Simon wrote:
I think I've discovered another problem with the current non-blocking API.
I have an application which reads data into fixed-size buffers which it
maintains per session. It uses non-blocking IO and select() when a read
returns SSL_ERROR_WANT_{READ,WRITE}.
To conserve memory I reduced the buffer size from 16384 to 8192 and saw
sessions suddenly hang. A coworker diagnosed this as follows:
1) The peer sends a SSL record larger than the buffer size.
2) We receive the SSL record. The socket selects as ready to read.
3) We call SSL_read with our 8k buffer. The received data does not fit,
so OpenSSL buffers it internally and returns 8K with SSL_ERROR_WANT_READ.
The record size of the SSL record is predetermined by the sender with
16k being the maximum size specified by the protocol.
In order to return the (decrytped and authenticated) data to the
application, the full record must have been received as the MAC
(Message Authentication Code) is at the end of the record and
checking it requires to calculate the hash over the complete record
anyway. Hence, SSL_read() will only return and provide data once
the full record has been recevied from the underlying socket.
As the SSL communication just like TCP is stream oriented there is no
way for an application to know what is the size of a record, whether
data are split over several records or sent in one or whether more
information inside the stream was combined to just one record.
Hence you have to read from the stream with SSL_read() until there is
no more data to be retrieved. As long as there are bytes available
SSL_read() will return the number of bytes written to the buffer.
A following call to SSL_get_errror(ssl, number of bytes) will return
SSL_ERROR_NONE. The logic here is quite simple: the first test in
ssl/ssl_lib.c:SSL_get_error() is:
if (i 0) return(SSL_ERROR_NONE);
Hence the scenario you describe here (returned 8k and
SSL_ERROR_WANT_READ at the same time) is technically impossible as
long as you did call SSL_get_error() with the correct return value of
SSL_read().
To find out whether there actually is decrypted data available to be read
you may use SSL_pending() before calling SSL_read().
I have written quite some amount of applications using non-blocking I/O
and while especially the shutdown behavior is questionable at least, the
actual
state machine never made any trouble to me.
Note: I did not invent the API, I just wrote the manual pages :-)
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: non-blocking SSL_read() API problem
Thor Lancelot Simon wrote:
On Fri, Aug 01, 2008 at 03:49:01PM +0200, Lutz Jaenicke wrote:
Thor Lancelot Simon wrote:
The record size of the SSL record is predetermined by the sender with
16k being the maximum size specified by the protocol.
32K for SSLv2, no?
I stopped caring for SSLv2 quite some time ago.
In order to return the (decrytped and authenticated) data to the
application, the full record must have been received as the MAC
(Message Authentication Code) is at the end of the record and
checking it requires to calculate the hash over the complete record
anyway. Hence, SSL_read() will only return and provide data once
the full record has been recevied from the underlying socket.
Yes, I understand this. The problem is that since the API doesn't include
SSL_select() or SSL_poll(), there's no way for an application to sleep
once SSL_read() consumes the data out of the socket buffer. This means
SSL_read() can't work quite like read(2) here -- it requires the read to
completion behavior you mention.
Yes.
This leads to another problem, actually:
A malicious peer which sends data as fast as it can can get _more_ data
into the socket buffer while the application is trying to read to
completion. This can deny service to _other_ peers.
This type of fairness has to be implemented by the application.
This will include modifying the event handling.
Basically an event-driven application which had an event loop like this
(which worked with the Unix model):
while (1)
{
select()
for(selected writable) {
write(it all);
}
for(selected readable) {
read(fixed size for fairness);
}
}
Now has to do something like this:
while (1)
{
select()
for(selected writable) {
SSL_write(it all);
}
for(SSL_pending() was true after last read) {
SSL_read(another fixed size chunk);
if (SSL_pending(this SSL)) {
flag as more coming in private datastructure;
}
}
for(selected readable) {
SSL_read(fixed size for fairness);
if (SSL_pending(this SSL)) {
flag as more coming in private datastructure;
}
}
}
This will work, but it will require restructuring the event loops of
many applications written to expect the Unix was (which is not great, but
so long as it's documented, it's better).
What kind of application are you talking about?
So far I have not seen any appliation that is collecting data from different
peers based on a amount of data sent round robin fashion. More or
less every application tends to have a higher level protocol with
handshake etc. that is actually responsible to deal with the peers
data.
Even though the interface might seem read()/write() compatible on the
first glance it finally is not and probably can never be as the protocol is
using bidirectional traffic for both read and write such that a simple
select model cannot be used.
The SSL_read() manual page should at least mention that it's unsafe to
call select again if SSL_pending() comes true. At present, it doesn't
mention SSL_pending() at all.
That is true indeed.
And this will work only as long as we're guaranteed SSL_pending() will
never actually read from the socket buffer, which someone might want to
make a note of somewhere!
It better should not because actually SSL_pending() should be
usable in the blocking case as well which would not hold if it
would actually try going down the chain.
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1260] [REQ] Include this root certificate with openssl sources
The OpenSSL distribution as of 0.9.8h is no longer shipped with any root CA certificates. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1645] Ehancement - The addition of GlobalSigns Roots into the default openSSL rootstore
The OpenSSL distribution as of 0.9.8h is no longer shipped with any root CA certificates. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1513] Bug : SSL_CTX_use_certificate_chain_file fails due to earlier errors
Respective patch applied, thanks. The fix will be in 0.9.8h. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1417] enhancement request: FAQ
Issue resolved by code modification, see ticket #1513. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Bodo Moeller wrote: However, another intentional use of potentially unitialized data is still left as of http://cvs.openssl.org/getfile/openssl/crypto/rand/randfile.c?v=1.47.2.2 : i=fread(buf,1,n,in); if (i = 0) break; /* even if n != i, use the full array */ RAND_add(buf,n,(double)i); Changing this into RAND_add(buf,i,(double)i) should make verification tools happier. Or it could be #ifdef PURIFY RAND_add(buf,i,(double)i); #else RAND_add(buf,n,(double)i); #endif (abusing the PURIFY macro with a more general meaning). Good catch, patch applied :-) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Will this change causes lock up?
Zhichao Hong wrote:
I have sent email about a client hangs when trying to communicating
with server using 0.9.7e version of the openssl. When looking into the
debugger stack trace, the ssl3_read_n blocks forever in the s3_pkt.c.
When I browsed the cvs change history, the following issue was fixed
later in Nov 2006. I am wondering without the fix (i.e. setting
s-first_packet to 0), will it cause some kind of locked up?
--- s3_pkt.c 2004/05/15 17:46:50 1.46.2.7
+++ s3_pkt.c 2006/11/29 14:44:07 1.46.2.8
@@ -275,11 +275,7 @@
n2s(p,rr-length);
/* Lets check version */
- if (s-first_packet)
- {
- s-first_packet=0;
- }
- else
+ if (!s-first_packet)
{
if (version != s-version)
{
Any insight will be very appreciated
Hmm, the full commit is at
http://cvs.openssl.org/chngview?cn=15686
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1609] openssl-0.9.8g - Bug report and maybe simple patch
The missing defitions have been added. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Will this change causes lock up?
Zhichao Hong wrote: Thank you, Lutz, for the change set information! I have to admit that I am not a power user of the openssl at the source level. We are not controlling the server as it is a standard IIS HTTPS. The software is using openssl library on top of openbsd stack. So do you know what is the impact on the client side if the fix are not applied? If I would have understood the impact I would have explained :-) . I did checkout the mailing lists around the date of commit and did not find any statement regarding this change. Sorry, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1552] mingw patch for openssl-0.9.8e
I have applied both the patch from Roumen Petrov and the Fixup from Alon Bar-Lev. I don't have a mingw environment to actually verify the correct operation. Please check out the next snapshot and verify that everything is working now as expected. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1451] Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
Closing as well according to #1552 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1659] NULL pointer dereference in rsautl bug and patch
I have applied a different modification which is a little bit more in line with the handling in other applications (where the handling seems to be correct). http://cvs.openssl.org/chngview?cn=17067 Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1607] Bug in openssl - file apps.c
Thanks, fixed in http://cvs.openssl.org/chngview?cn=17069 (0.9.8-stable) http://cvs.openssl.org/chngview?cn=17068 (HEAD) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1660] Request for feature, all Windows systems, all OpenSSL versions.
I agree with Shaw Graham George's post on openssl-dev. Modifying system settings upon installation would seem to be too intrusive for the OpenSSL source package. OpenSSL as distributed by the OpenSSL team does not modify system settings during installation on any platform. Typically integrators providing distributions like (name-your-favorite) Linux distribution are providing such functions as their value add... and besides they do know more about the specific installation requirements than we do. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 64 bits computer always returns the same salt
David Erosa García wrote:
Hello all.
I tried the openssl-users list but I think this may be a question for
the devel list:
I'm doing my homework about openssl, but *this question has nothing to
do with it*. It's just a doubt that arised while doing it.
There is one exercise with the following text:
Con el comando “openssl enc” y la siguiente clave AES:
188458A6D15034DFE386F23B61D43774 se puede descifrar cierta información.
Podrías decir cual?
Using the command openssl enc and the following AES key:
188458A6D15034DFE386F23B61D43774 you can decode some information, could
you say what?
I started playing with openssl enc and I thought the only thing I
could guess was the salt (Surely I'm wrong).
So I ran the command with a random IV:
openssl enc -aes128 -K 188458A6D15034DFE386F23B61D43774 -iv 1 -P
I found that the salt varies as it should on two machines with 32 bit
CPU (not my main one):
Office's computer (openssl 0.9.8g-4ubuntu2):
salt=4075DFB76496F2B7
salt=4045D8B76466EBB7
salt=40C5DAB764E6EDB7
salt=4015DEB76436F1B7
salt=4025DFB76446F2B7
A server I have somewhere else (openssl 0.9.8c-4etch1):
salt=50D882BF0C00
salt=B05DD9BF0C00
salt=A0CCC7BF0C00
salt=E0C88BBF0C00
salt=204190BF0C00
But when I run it on my main computer, it always outputs the same salt!
This machine is a 64bit CPU, running a 64bits linux distribution
(openssl 0.9.8g-4ubuntu2):
salt=0004
salt=0004
salt=0004
salt=0004
I've been searching through the openssl lists and found nothing about
this behavior.
What can be happening? Is it about the 64 bit version of openssl?
No, the actual output may depend on the system but the reason behind it
is found in apps/enc.c:
...
if (cipher != NULL)
{
/* Note that str is NULL if a key was passed on the command
* line, so we get no salt in that case. Is this a bug?
*/
if (str != NULL)
...
In the case the str == NULL the memory containing the salt is an
uninitialized part of the stack so its content is undefined and the
behavior will depend on system and compiler (options) used.
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1663] bug report openssl-0.9.8g on Windows XP
Andrew Lamoureux via RT wrote: Hi, I'd like to report a bug in openssl-0.9.8g compiled with Visual Studio. OS is Windows XP. Access violation occurs when BN_rshift() is used on a BIGNUM whose bit length is less (amount required varies) than the number of bits requesting to be shifted. Here is very simple code that reliably reproduces the problem: BIGNUM * bnp = BN_new(); BN_rand(bnp, 64, 0, 0); BN_rshift(bnp, bnp, 67); It does crash in BN_rshift() with a segmentation violation on Linux as well. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1662] key generation creates world-readable keys by default
OpenSSL does create keys in more components than just gen(r|d)sa. In none of these functions any file permission mask is used. All of the components in openssl/apps are using the file-BIO which behaves like stdio and does not have idea about file permissions. People using OpenSSL to generate their keys should rather use safe umask settings. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1661] README file references a non-existing URL
That is indeed true. I have migrated RT quite a lot of time ago but did miss the obvious references in the process. * fixed the URI in the respective files for future releases * added a redirection at the URI provided to the new page Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1641] [Patch] uninitialized variable in bn_mont.c
Closing according to respective email on [EMAIL PROTECTED] Hi, a couple of days ago I've reported the bug: http://rt.openssl.org/Ticket/Display.html?id=1641 It looks like that Bodo's commit (see below) has fixed the reported problem. So the bug can be closed and set to fixed. Best regards, Christian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Minor bug in verify manpage
Richard Hartmann wrote: Hi all, 3 X509_V_ERR_UNABLE_TO_GET_CRL unable to get certificate CRL should read 3 X509_V_ERR_UNABLE_TO_GET_CRL: unable to get certificate CRL i.e. there is a colon missing. If there is any interest, I can create a patch but it is probably faster for both sides if someone with commit access just fixes this him- or herself. Applied. Thanks, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Administrivia and seasons greetings
Guenter Knauf wrote: Hi Lutz, Replies to active tickets are handled automatically. I've a ticket open where I posted a couple of times updates: http://rt.openssl.org/index.html?q=1611 but nothing of these appear here on the list - although they are properly listed with #1611... can you tell me what I'm probably doing wrong? I don't know what goes wrong for you. All of the mails have been sent to the mailing list: I have checked both my personal mailbox as well as public mail archives. Hint: my Thunderbird marked the mails as possible SCAM. Do you have any automatic SPAM filter? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Display the CRL number w/o -text [patch included]
Bruno Bonfils wrote: Hi openssl's people, I'm currently writing a script to check a PKI. For this purpose, I wrote a small patch to display the crlNumber directly from the crl's app: # openssl crl -in ca.crl -crlnumber -noout crlNumber=42 I'll happy if the patch can be include in upstream. Thanks for your submission. Could you kindly submit your proposed patch in unified diff format to OpenSSL's request tracker? http://www.openssl.org/support/rt.html Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: powerpcc64 debian and -DOPENSSL_USE_GMP -lgmp
Robert Gries wrote: Well even though I get the error about the shared libraries, it did work with is Configure: ./Configure --prefix=~gries/usr/local/ssl --openssldir=~gries/usr/local/ssl threads linux-ppc64 -m64 -L/usr/local/lib -DOPENSSL_USE_GMP -lgmp -static [EMAIL PROTECTED]:~/openssl-0.9.8g$ apps/openssl speed rsa -engine gmp invalid engine gmp 27835:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:162:filename(~gries/usr/local/ssl/lib/engines/libgmp.so): ~gries/usr/local/ssl/lib/engines/libgmp.so: cannot open shared object file: No such file or directory 27835:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: ... Did you actually read the error messages shown? They indicate that OpenSSL tries to load the engine from ~gries/usr/local/ssl/lib/engines/libgmp.so Did you check whether libgmp.so is actually installed? From my best understanding ~gries is a shell'ism and is most likely not supported by the dynamic loader. You should rather pass $(HOME)/usr/local/ssl on the command line such that the shell expands the full path and the openssl configuration has the full path compiled in. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Please add OIDs for CMP and CRMF to objects.txt
Martin Peylo wrote: Hi, could the following OIDs please be added to the objects.txt file? They are used by CMP (RFC 4210) and CRMF (RFC 4211) which I am implementing right now. This would make it easier for me to supply a patch which applies cleanly in case the objects.txt file was changed in the meantime. # Macs for CMP and CRMF ISO-US 113533 7 66 13 : id-PasswordBasedMAC : password based MAC ISO-US 113533 7 66 30 : id-DHBasedMac : Diffie-Hellman based MAC # HMAC OIDs identified-organization 6 1 5 5 8 1 1 : HMAC-MD5 : hmac-md5 identified-organization 6 1 5 5 8 1 2 : HMAC-SHA1 : hmac-sha1 # (additional) CMP information types id-it 16: id-it-suppLangTags So done in 0.9.8-stable and -dev. Please test out the next snapshots. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1594] 0.9.8f build problem on HP-UX 11.23 ia64
This should be fixed by commit http://cvs.openssl.org/chngview?cn=16682 Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1590] OpenSSL 0.9.8f: bad SHA1, questionable PGP
The SHA1 was recreated and the tarball was resigned by myself. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1589] OPENSSL_VERSION_NUMBER wrong in 0.9.8f release
[jaenicke - Fri Oct 19 11:39:05 2007]: This will never be fixed in the 0.9.8f tarball (as it was rolled as is). OpenSSL 0.9.8g has now been released using a correct version code. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1591] get_session_cb callback invoked with no previous session in 0.9.8f
Fixed in 0.9.8g __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL version 0.9.8g released
OpenSSL version 0.9.8g released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8g of our open source toolkit for SSL/TLS. This new OpenSSL version is a bugfix release. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. We consider OpenSSL 0.9.8g to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.8g.tar.gz MD5 checksum: acf70a16359bf3658bdfb74bda1c4419 SHA1 checksum: 4e9c5ced466715d18fd924de79bde5c15da80fa1 The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf M�ller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz J�nickeBodo M�ller -BEGIN PGP SIGNED MESSAGE- OpenSSL version 0.9.8g released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8g of our open source toolkit for SSL/TLS. This new OpenSSL version is a bugfix release. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. We consider OpenSSL 0.9.8g to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.8g.tar.gz MD5 checksum: acf70a16359bf3658bdfb74bda1c4419 SHA1 checksum: 4e9c5ced466715d18fd924de79bde5c15da80fa1 The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBRxhvVXiZOxScWKZtAQGtrgP/UeZPGx3YlBis9yLyqy5rRVys3pzlLAgH a0dJx+Ig/qTsuUK5CNmBk34xymlzVTmUlZZxnhJeQf9dd1FfJqhPhQVed3ejhGif 0C5MzLv6ywPPp6GqJb5HDD1C2PbdgD4eguR0zumHUDcWU09zTRIl9LAFgCKWiE8N IBIpBai+2+o= =Dr0o -END PGP SIGNATURE-
[openssl.org #1589] OPENSSL_VERSION_NUMBER wrong in 0.9.8f release
Your statement is actually correct. Nevertheless it does not seem to be useful to create a new release (0.9.8g) just to correct an informational version number code. It also would not be a good idea to create a new tarball with the same name but just a new version number code. We have therefore decided to leave the tarball as is and work around using another version code for the time being. http://cvs.openssl.org/chngview?cn=16688 Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1590] OpenSSL 0.9.8f: bad SHA1, questionable PGP
I have made the following modifications to the download area (not tracked by CVS, so the action is not logged via openssl-cvs) at Wed Oct 17, 2007, 09:30 CEST (07:30GMT): * updated openssl-0.9.8f.tar.gz.sha1 * created new openssl-0.9.8f.tar.gz.asc with my (Lutz Jaenicke) personal key matching the listed in http://www.openssl.org/about/ in ascii-armor * moved old signature file from Ben using a key not listed on the About page to openssl-0.9.8f.tar.gz.sig (.sig should be fine for a binary signature) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1590] OpenSSL 0.9.8f: bad SHA1, questionable PGP
Grr. The OpenSSL web site is some (semi-)automatic thing that is updated in a magic way. Probably only Ralf Engelschall fully understands how this works :-) I have made sure the correct files are linked now. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1591] get_session_cb callback invoked with no previous session in 0.9.8f
[EMAIL PROTECTED] - Wed Oct 17 18:11:27 2007]: Starting with OpenSSL 0.9.8f, ssl3_get_client_hello() no longer tests whether the client proposed a previous session_id before trying to process it. In previous releases, a new session was always created if no previous session was proposed (i.e. if j==0 at ssl\s3_srvr.c:746) The problem is being worked upon. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1578] [PATCH] fix is is typos
Applied, thanks. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #521] [PATCH] Avoid uninitialized data in random buffer
A respective compile time macro PEDANTIC (to be added to the C flags as -DPEDANTIC) has been added for OpenSSL 0.9.8f. The behavior has been clarified in the manual page and the FAQ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to Submit a patch
Nitin M wrote: Hi! Can anyone please tell me the correct way to submit a patch here, as I have never done that before on this list? As stated somewhere on the website: submit it by email to [EMAIL PROTECTED] Note: wrt SPAM protection this interface is moderated so there may be some delay(*) before the request becomes public. (*) delay being between minutes and several hours depending on when I find the time to look into the queue of incoming requests. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Ben Laurie schrieb: Lutz Jaenicke wrote: Lutz Jaenicke wrote: Peter Waltenberg wrote: Yes, it's desirable that that data is unknown however there is a compromise possible: Complement the area. It'll mean valgrind will only complain at the correct place, or possibly not at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. Not being a valgrind user... I do not see that leaving this area uninitialized will give us some cryptographically useful amount of entropy so that we could as well memset it to 0... Ok, I have just applied the patch to 0.9.8-stable and 0.9.9-dev. Oi. Don't do that. Why not? Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Peter Waltenberg wrote: Yes, it's desirable that that data is unknown however there is a compromise possible: Complement the area. It'll mean valgrind will only complain at the correct place, or possibly not at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. Not being a valgrind user... I do not see that leaving this area uninitialized will give us some cryptographically useful amount of entropy so that we could as well memset it to 0... Regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1499] Uninitialized value in RAND_load_file, with -DPURIFY
Guessing on the stack being non-predictable does not seem to improve entropy too much to me. I have therefore modified the code to no longer use uninitialized memory in any case. Not relying on -DPURIFY will also make valgrind users happy :-) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: STARTTLS patch for imap and ftp
Goetz Babin-Ebell wrote: Lutz Jaenicke wrote: Goetz Babin-Ebell wrote: [...] * in SMTP doing a STARTTLS without previous EHLO will return a 503 STARTTLS command used when not advertised * in IMAP doing a STARTLS requires a . CAPABILITY first. In both cases the server response should be parsed for the string STARTTLS... This statement is technically correct. As the s_client tool is however intended for testing purposes only (you remember that a capital R at the beginning of the line will start a renegotiation instead of being transferred to the server :-) adding the EHLO and .CAPABILITY should be sufficient and the more complex parsing of the response might be omitted... Do you want something like the attached patch ? (untested, I'm off to bed...) Ok, I have reworked this section as discussed by using a buffering BIO and have committed everything to CVS. I would be most pleased if somebody would also cross-test it (the part with the multi-line IMAP response may require some more digging as the termination should be the . at the beginning of the response line, not the number of chars being less than 3!?) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1459] Bug in quoting string expressions
Patch applied. Thanks, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1277] add support for m68k linux
Applied to openssl-0.9.8 and openssl-dev trees. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1152] add support for Linux on SuperH
Applied to openssl-0.9.8 and openssl-dev. Thanks, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: STARTTLS patch for imap and ftp
Goetz Babin-Ebell wrote:
Lutz Jaenicke wrote:
Goetz Babin-Ebell wrote:
[...]
* in SMTP doing a STARTTLS without previous EHLO
will return a
503 STARTTLS command used when not advertised
* in IMAP doing a STARTLS requires a
. CAPABILITY
first.
In both cases the server response should be parsed for
the string STARTTLS...
This statement is technically correct. As the s_client tool is however
intended for testing purposes only (you remember that a capital
R at the beginning of the line will start a renegotiation instead
of being transferred to the server :-) adding the EHLO and .CAPABILITY
should be sufficient and the more complex parsing of the response
might be omitted...
Do you want something like the attached patch ?
(untested, I'm off to bed...)
Yes, something like this. I have applied your patch to 0.9.8 and -dev... and
was just going to write thank you when I discovered that it does not work.
As I just noted BIO_read() does not work line by line but on the message
coming in. This message is the complete multi-line response and it has
to be parsed in a different way as attached as a crude hack.
No: BIO_gets() does not work on here (not supported on connect BIO.
Yes: all other appearances of multi-line handling are broken as well.
The multi-line handling in the SMTP greeting would fail on the first
host with a multi-line greeting and the other protocol handlers are
as buggy. I have thus left your patch in and we have to decide how to
tackle the other occurances...
Best regards,
Lutz
Index: s_client.c
===
RCS file: /e/openssl/cvs/openssl/apps/s_client.c,v
retrieving revision 1.76.2.7
diff -u -r1.76.2.7 s_client.c
--- s_client.c 21 Feb 2007 18:20:33 - 1.76.2.7
+++ s_client.c 21 Feb 2007 18:53:00 -
@@ -735,7 +735,7 @@
/* This is an ugly hack that does a lot of assumptions */
if (starttls_proto == PROTO_SMTP)
{
- int foundit=0;
+ int foundit=0, response_done = 0;
/* wait for multi-line response to end from SMTP */
do
{
@@ -747,11 +747,15 @@
/* wait for multi-line response to end EHLO SMTP response */
do
{
+ int ll;
mbuf_len = BIO_read(sbio,mbuf,BUFSIZZ);
if (strstr(mbuf,STARTTLS))
foundit=1;
+ for (ll = 0; !response_done ll mbuf_len - 4; ll++)
+if (mbuf[ll] == '\n' mbuf[ll + 3] != '-')
+ response_done = 1;
}
- while (mbuf_len3 mbuf[3]=='-');
+ while (mbuf_len3 mbuf[3]=='-' !response_done);
if (!foundit)
BIO_printf(bio_err,
didn't found starttls in server response,
Re: STARTTLS patch for imap and ftp
Dr. Stephen Henson wrote:
On Wed, Feb 21, 2007, Lutz Jaenicke wrote:
Goetz Babin-Ebell wrote:
Lutz Jaenicke wrote:
Goetz Babin-Ebell wrote:
[...]
* in SMTP doing a STARTTLS without previous EHLO
will return a
503 STARTTLS command used when not advertised
* in IMAP doing a STARTLS requires a
. CAPABILITY
first.
In both cases the server response should be parsed for
the string STARTTLS...
This statement is technically correct. As the s_client tool is however
intended for testing purposes only (you remember that a capital
R at the beginning of the line will start a renegotiation instead
of being transferred to the server :-) adding the EHLO and .CAPABILITY
should be sufficient and the more complex parsing of the response
might be omitted...
Do you want something like the attached patch ?
(untested, I'm off to bed...)
Yes, something like this. I have applied your patch to 0.9.8 and -dev... and
was just going to write thank you when I discovered that it does not work.
As I just noted BIO_read() does not work line by line but on the message
coming in. This message is the complete multi-line response and it has
to be parsed in a different way as attached as a crude hack.
No: BIO_gets() does not work on here (not supported on connect BIO.
Note that adding a buffering BIO to the chain is a simple way to fix this.
Yes. I get your point :-)
Best regards,
Lutz
Index: apps/s_client.c
===
RCS file: /e/openssl/cvs/openssl/apps/s_client.c,v
retrieving revision 1.76.2.7
diff -u -r1.76.2.7 s_client.c
--- apps/s_client.c 21 Feb 2007 18:20:33 - 1.76.2.7
+++ apps/s_client.c 21 Feb 2007 19:55:21 -
@@ -736,22 +736,28 @@
if (starttls_proto == PROTO_SMTP)
{
int foundit=0;
+ BIO *fbio = BIO_new(BIO_f_buffer());
+ BIO_push(fbio, sbio);
/* wait for multi-line response to end from SMTP */
do
{
- mbuf_len = BIO_read(sbio,mbuf,BUFSIZZ);
+ mbuf_len = BIO_gets(fbio,mbuf,BUFSIZZ);
}
while (mbuf_len3 mbuf[3]=='-');
/* STARTTLS command requires EHLO... */
- BIO_printf(sbio,EHLO openssl.client.net\r\n);
+ BIO_printf(fbio,EHLO openssl.client.net\r\n);
+ BIO_flush(fbio);
/* wait for multi-line response to end EHLO SMTP response */
do
{
- mbuf_len = BIO_read(sbio,mbuf,BUFSIZZ);
+ mbuf_len = BIO_gets(fbio,mbuf,BUFSIZZ);
if (strstr(mbuf,STARTTLS))
foundit=1;
}
while (mbuf_len3 mbuf[3]=='-');
+ BIO_flush(fbio);
+ BIO_pop(fbio);
+ BIO_free(fbio);
if (!foundit)
BIO_printf(bio_err,
didn't found starttls in server response,
Re: STARTTLS patch for imap and ftp
Goetz Babin-Ebell wrote: Hello Richard, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 15 Feb 2007 10:34:23 -0800, Kees Cook [EMAIL PROTECTED] said: kees 3 years ago, I wrote a patch[1] (and did the TSU[2]) for adding kees these features to s_client. Can this please be applied to CVS? Yes. Done. Thank you, and sorry you had to wait 3 years for this to happen. The problem (not only I have) with the patch is that at least in SMTP and IMAP it is illegal to start TLS before an initial protocol handshake is done: * in SMTP doing a STARTTLS without previous EHLO will return a 503 STARTTLS command used when not advertised * in IMAP doing a STARTLS requires a . CAPABILITY first. In both cases the server response should be parsed for the string STARTTLS... This statement is technically correct. As the s_client tool is however intended for testing purposes only (you remember that a capital R at the beginning of the line will start a renegotiation instead of being transferred to the server :-) adding the EHLO and .CAPABILITY should be sufficient and the more complex parsing of the response might be omitted... Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[Fwd: [openssl.org #1480]]
RT access configuration has been changed. Best regards, Lutz ---BeginMessage--- This transaction appears to have no content __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] ---End Message---
Re: OpenSSL request tracker downtime
Lutz Jaenicke wrote: Lutz Jaenicke wrote: Hi! The OpenSSL request tracker will go down now for migration to a new version of RT and another host. All incoming email requests will be queued and will be uploaded once the new setup is finished. I will send another announcement once the request tracker is back up online. Unfortunately the migration did not work as smooth as expected. I have re-enabled the old instance for the time being. Ok, I have worked out the problems of the new setup and will make a new attempt now. Request tracker at aet.tu-cottbus.de will go down now. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1469] Testing
Testing the new installation of RT for OpenSSL before declaring it live. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1469] Testing
Lutz Jaenicke via RT wrote: Testing the new installation of RT for OpenSSL before declaring it live. Testing the mail gateway before declaring it live. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1469] Testing
Lutz Jaenicke via RT wrote: Testing the new installation of RT for OpenSSL before declaring it live. Testing the mail gateway before declaring it live. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL request tracker downtime
Lutz Jaenicke wrote: Lutz Jaenicke wrote: Lutz Jaenicke wrote: Hi! The OpenSSL request tracker will go down now for migration to a new version of RT and another host. All incoming email requests will be queued and will be uploaded once the new setup is finished. I will send another announcement once the request tracker is back up online. Unfortunately the migration did not work as smooth as expected. I have re-enabled the old instance for the time being. Ok, I have worked out the problems of the new setup and will make a new attempt now. Request tracker at aet.tu-cottbus.de will go down now. Request tracker has now been migrated to http://rt.openssl.org/ The email address stays at [EMAIL PROTECTED] or openssl-bugs@openssl.org I will do some more fine tuning and tests over the next hours and days. For the time being it seems that outgoing mails to openssl-dev are sent twice. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1469] Testing
Lutz Jaenicke via RT schrieb: Testing the new installation of RT for OpenSSL before declaring it live. Testing with modified settings. Duplicate emails to openssl-dev should now be gone. Hopefully... Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[EMAIL PROTECTED]: request for the source code....]
Forwarded to the openssl-dev mailing list for discussion. Best regards, Lutz - Forwarded message from jha sudhir [EMAIL PROTECTED] - X-Original-To: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Greylist: delayed 399 seconds by postgrey-1.27 at master.openssl.org; Fri, 26 Jan 2007 21:13:43 CET DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EH8B9nfXZm3Yjpo4n+pYXCdz8/Qz6Lxxy9dbQOXZG3pe47jTmYHdHwSDYFpxVIFLOvSvL8pPyeGQP8d0zNSISxF0arPSmyMFrt10TxgIMZBpBMFXtwNX5mVj1abpeXnUbt6eUINukwg7UwbqNsj+fGqwKgFwqscADVvWOVHPK3Y= ; X-YMail-OSG: pmbxfmkVM1mivif.h7n8z8CyduPekZtuMH6GQKQE2D3BrSZ7CgP97rgUIFXN74rtzxOoGC5ZJDB0zX3Iotne3Q14ijNnl2gmCHS7lRFGVCUhLJdig7NZE5EAhxbVbdI062DsUNcsVW8qT4VFUH1Ymng9 Date: Fri, 26 Jan 2007 20:06:23 + (GMT) From: jha sudhir [EMAIL PROTECTED] Subject: request for the source code To: [EMAIL PROTECTED] X-Virus-Scanned: by amavisd 0.1 X-Virus-Scanned: by amavisd 0.1 Hi , this is sudhir jha from chennai.i m final year student doing my Btech frm computer science. rit now we have our projects ...and mine is Implemention of ECC algo on ssl vr 3.0.tht i dont know how to perform as well as validate it. so i am loking for your kind help if u could ..pls reply soon. bye, sudhir jha - Heres a new way to find what you're looking for - Yahoo! Answers - End forwarded message - -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL request tracker downtime
Hi! The OpenSSL request tracker will go down now for migration to a new version of RT and another host. All incoming email requests will be queued and will be uploaded once the new setup is finished. I will send another announcement once the request tracker is back up online. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL request tracker downtime
Lutz Jaenicke wrote: Hi! The OpenSSL request tracker will go down now for migration to a new version of RT and another host. All incoming email requests will be queued and will be uploaded once the new setup is finished. I will send another announcement once the request tracker is back up online. Unfortunately the migration did not work as smooth as expected. I have re-enabled the old instance for the time being. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1459] Bug in quoting string expressions
The attached patch fixes an incorrect handling of special characters. Patch is against 0.9.8d. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1457] Error while building openssl on ppc64 with gcc...
Atul Kulkarni (SIGSEC) via RT wrote: That seems to be a bug with openssl dev package, as I am trying to build on a native ppc64 machine why should it add a -b directive asking for a cross-compilation machine. Please note my code compiles without it though! If there is any specific reason that I am missing please let me know. There is a comment in the Configure file that reads # -bpowerpc64-linux is transient option, -m64 should be the one to use... so it might be worth adding another Configure target or fix the old one... Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
