Re: "openssl dgst" ignores read errors

2002-05-10 Thread Solar Designer

On Mon, Apr 29, 2002 at 03:48:48PM +0100, Ben Laurie wrote:
> Solar Designer wrote:
> > it could also be nice to report the filename and strerror(errno), or
> > it is sometimes not immediately clear what the error messages apply to:
> > 
> > jill!solar:~/build/openssl-SNAP-20020416$ apps/openssl dgst -md5 /bin/ls /dev/log 
>/bin /usr/bin/id
> > MD5(/bin/ls)= d93498d9f52c3dc0330ab930fe3ffc50
> > Read Error
> > Read Error
> > MD5(/usr/bin/id)= 4b37435d0793aba2b602fd2da0d7f8c5
> > jill!solar:~/build/openssl-SNAP-20020416$ echo $?
> > 0
> > 
> > ...and the zero exit status in that case is even worse.
> > 
> > I am thinking something like "fread: /bin: Is a directory" printed to
> > stderr and a non-zero exit if at least one of the arguments resulted in
> > an error.
> 
> Well, here's an even bigger and better patch. Thanks for the continued
> feedback.

OK, I've now tested this patch applied to 0.9.6d (by the way, the
announcement message incorrectly mentions "beta 1" in the Subject
line).  It works as desired, thanks!  I wouldn't make the messages
this verbose for uses from within the openssl binary, but that's
up to you.

I'll be updating the OpenSSL package in Owl to 0.9.6d + this patch
now.

Thank you once again.

-- 
/sd
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Announce: Time Stamp Protocol (RFC 3161) patch

2002-05-10 Thread Zoltan Glozik

Hi All,

I am working on an extension to OpenSSL that implements the Time Stamp
protocol as specified in RFC 3161 and it reached a quite stable state to
make it available to the public. If you are interested you can find the
patch for openssl-engine-0.9.6d, installation instructions and manual at
this URL:
http://glozik-zoltan.int.eu.org/tsa/

Implemented features:
- A new 'ts' command was added through which the time stamping functionality
can be accessed.
- You can create a new DER encoded time stamp request (TimeStampReq) based
on a data file. All the hash algorithms supported by OpenSSL can be used for
creating the message imprint.
- You can generate a DER encoded signed time stamp response (SignedData)
based on a time stamp request.
- A time stamp response can be validated against a time stamp request.

New features I am still working on:
- A module for Apache which would make use of OpenSSL and would act as a
Time Stamp Authority, accessible over either HTTP or HTTPS.
- An HTTP and HTTPS command-line driven time stamp client.

If you want to test or use the code your questions, feedback and bug reports
are very welcomed.

Best Regards,
Zoltan Glozik


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[Fwd: testlog]

2002-05-10 Thread V. M. Brasseur

I keep hitting a failure for 'make test' on a 64-bit IBM-AIX.  A google
search isn't turning up anthing that can help me out.  I'm hoping ya'll
could maybe lend a hand.

Many thanks in advance.

--V

iii guy wrote:
> 
> OpenSSL self-test report:
> 
> OpenSSL version:  0.9.6a
> Last change:  Fix a couple of memory leaks in PKCS7_dataDecode()...
> OS (uname):   AIX denali 3 4 000BFC4F4C00
> OS (config):  000BFC4F4C00-ibm-aix43
> Target (default): aix43-cc
> Target:   aix43-cc
> Compiler: exec: 
>/usr/bin/pg(/usr/bin/pg,//usr/vac/exe/default_msg/vac.help,NULL)
>   C for AIX Compiler, Version 5
> 
>   Usage:
>  xlc [ option | inputfile ]...
>  cc [ option | inputfile ]...
>  c89 [ option | inputfile ]...
>  xlc128 [ option | inputfile ]...
>  cc128 [ option | inputfile ]...
>  xlc_r [ option | inputfile ]...
>  cc_r [ option | inputfile ]...
>  xlc_r4 [ option | inputfile ]...
>  cc_r4 [ option | inputfile ]...
>  xlc_r7 [ option | inputfile ]...
>  cc_r7 [ option | inputfile ]...
> 
>   Description:
>  The xlc and related commands compile C source files.
>  They also processes assembler source files and object files. Unless the
>  -c option is specified, xlc calls the linkage editor to produce a
>  single object file. Input files may be any of the following:
>1. file name with .c suffix: C source file
>2. file name with .i suffix: preprocessed C source file
>3. file name with .so suffix: shared object file
>4. file name with .o suffix: object file for ld command
>5. file name with .s suffix: assembler source file
> 
>   Options:
>  Options can be flag options or keyword options:
> 
>1. Flag options:
> 
> -#Display language processing commands but do
>   not invoke them; output goes to stdout.
> -bdynamic, -bstatic
>   Determines which types of library files are searched by
>   the linkage editor.
> -brtl Tells the linkage editor to accept both .so and .a
>   library file types.
> -B
>   Construct alternate compiler/assembler/linkage editor
>   program names.  is added to the beginning of
>   the standard program names.
> -cDo not send object files to the linkage editor.
> -CWrite comments to output when doing preprocessing,
>   used with -E and -P.
> -D[=]
>   Define  as in #define directive. If  is
>   not specified, 1 is assumed.
> -EPreprocess but do not compile; output goes to stdout
> -f
>   Passes to the linkage editor the filename of a file
>   containing a list of input files to be processed.
> -F[:]
>   Use alternate configuration file  with optional
>   . If  is not specified, the assumed stanza
>   is the name of the command used to invoke the compiler.
> -gProduce information for the debugger.
> -GTells the linkage editor to create a dynamic library.
> -I   Search in directory  for include files that
>   do not start with an absolute path.
> -l   Search the specified library file,
>   where  selects the file lib.a.
> -L   Search in directory  for files specified by -l.
> -ma   Generate inline calls to the "alloca" function as if
>   "#pragma alloca" directives were in the source file.
> -MGenerate information to be included in a "make"
>   description file; output goes to .u file.
> -o  Name the executable file  instead of a.out.
>   When used with the -c option and one source file,
>   name the object file  instead of filename.o.
>   If  is the name of a directory, files generated by
>   the compiler will be placed into that directory.
> -OOptimize generated code.
> -O2   Same as -O.
> -O3   Perform some memory and compile time intensive
>   optimizations in addition to those executed with -O2.
>   The -O3 specific optimizations have the potential to
>   alter the semantics of a user's program.
>   The compiler guards against these optimizations at -O2
>   and the option -qstrict is provided at -O3 to turn off
>   these aggressive optimizations.
> -O4   Equivalent to -O3 -qipa with automatic generation of
>   architecture and tuning option ideal for that platform.
> -O5   Equivalent to -O3 -qipa=level=2 with automatic generation of
>   architecture and tuning option ideal for that platform.
> -p  

Re: [openssl.org #26] 64 bit Suse Linux on PowerPC

2002-05-10 Thread John Bihlmeyer

Thank you Lutz and Tim.
By configuring with the following:
./Configure linux-ppc
I was able to run "make" successfully and then run "make test" and "make
install"
successfully as well.
I was able therefore to successfully build, run the build verification
tests and
install on the 64 bit Suse Linux on powerPC.
Now all we need to do is get ./config to recognize this environment as
"linux-ppc"
and we will be fine.
Thanks again.
John

"Lutz Jaenicke via RT" <[EMAIL PROTECTED]>@openssl.org on 05/09/2002 04:25:26
PM

Please respond to [EMAIL PROTECTED]

Sent by:[EMAIL PROTECTED]


To:John Bihlmeyer/Raleigh/IBM@IBMUS
cc:[EMAIL PROTECTED]
Subject:[openssl.org #26] 64 bit Suse Linux on PowerPC




[[EMAIL PROTECTED] - Thu May  9 22:13:32 2002]:

> I am trying to compile on a 64 bit Suse sles7 powerpc system.
> the error message indicates
>
> -m486
>
> is an invalid compiler parameter. Anyone know the parameters I need to
give
> ./config to
> get it to work for 64 bit Suse on a powerpc
>
> below are the results from running ./config without parameters and the
> results from running the make command.

> Operating system: ppc64-whatever-linux2
> Configuring for linux-elf

Obviously "config" mistakenly selects the "linux-elf" target that is
used for x86 platforms. (This is a bug that has to be fixed.)

Configure also contains an entry for "linux-ppc", I however don't know
whether it is suitable for 64bit PowerPC.
Please try "Configure linux-ppc" directly instead of calling "config"
and keep us updated, whether it works out.

Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[ANNOUNCE] OpenSSL 0.9.6d beta 1 released

2002-05-10 Thread Richard Levitte - VMS Whacker

  OpenSSL version 0.9.6d 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.6d of our open source toolkit for SSL/TLS.  This new OpenSSL version
  is mostly a bugfix release and incorporates at least 23 changes to the
  toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES).

  The most significant changes are:

o Various SSL/TLS library bugfixes.
o Fix DH parameter generation for 'non-standard' generators.

  We consider OpenSSL 0.9.6d 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.6d 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):

o http://www.openssl.org/source/
o ftp://ftp.openssl.org/source/

  [1] OpenSSL comes in the form of two distributions this time.
  The reasons for this is that we want to deploy the external crypto device
  support but don't want to have it part of the "normal" distribution just
  yet.  The distribution containing the external crypto device support is
  popularly called "engine", and is considered experimental.  It's been
  fairly well tested on Unix and flavors thereof.  If run on a system with
  no external crypto device, it will work just like the "normal" distribution.

  The distribution file names are:

  o openssl-0.9.6d.tar.gz [normal]
  o openssl-engine-0.9.6d.tar.gz [engine]

  Yours,
  The OpenSSL Project Team...  

Mark J. Cox Richard LevitteAndy Polyakov
Ralf S. Engelschall Bodo MöllerHolger Reif
Dr. Stephen Henson  Ulf Möller Geoff Thorpe
Ben Laurie  Lutz Jänicke   
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



SSL_shutdown.3 makewhatis failure under IRIX

2002-05-10 Thread Rick Troxel

In order for makewhatis -M under IRIX 6.5.14m not to fail on
SSL_shutdown.3 as follows:

   nroff: Macro argument too long; line 170, file
 /usr/local/man/man3/SSL_shutdown.3
   stack: N"

I found it necessary (well, at least it was sufficient) to recast the
long

.Ip "...\*(N"...\*(T"..." 4

lines as

.Ip
...\*(L"...\*(R"...

The version is openssl-0.9.6c, in case that should matter.  I did not
have to change the corresponding .IX Item lines.  A context diff is
attached.

FWIW,
-- 
Rick Troxel, Helix Systems Staff [EMAIL PROTECTED] 301/435-2983


*** ../SSL_shutdown.3.ORIG  Tue Mar 26 14:38:39 2002
--- SSL_shutdown.3  Thu May  9 15:58:29 2002
***
*** 218,225 
  .PP
  \fISSL_shutdown()\fR supports both uni- and bidirectional shutdown by its 2 step
  behaviour.
! .Ip "When the application is the first party to send the \*(N"close notify\*(T" 
alert, SSL_shutdown() will only send the alert and the set the 
\s-1SSL_SENT_SHUTDOWN\s0 flag (so that the session is considered good and will be kept 
in cache). SSL_shutdown() will then return with 0. If a unidirectional shutdown is 
enough (the underlying connection shall be closed anyway), this first call to 
SSL_shutdown() is sufficient. In order to complete the bidirectional shutdown 
handshake, SSL_shutdown() must be called again. The second call will make 
SSL_shutdown() wait for the peer's \*(N"close notify\*(T" shutdown alert. On success, 
the second call to SSL_shutdown() will return with 1." 4
! .Ip "If the peer already sent the \*(N"close notify\*(T" alert \fBand\fR it was 
already processed implicitly inside another function (SSL_read(3)), the 
\s-1SSL_RECEIVED_SHUTDOWN\s0 flag is set. SSL_shutdown() will send the \*(N"close 
notify\*(T" alert, set the \s-1SSL_SENT_SHUTDOWN\s0 flag and will immediately return 
with 1. Whether \s-1SSL_RECEIVED_SHUTDOWN\s0 is already set can be checked using the 
SSL_get_shutdown() (see also SSL_set_shutdown(3) call." 4
  .PP
  It is therefore recommended, to check the return value of \fISSL_shutdown()\fR
  and call \fISSL_shutdown()\fR again, if the bidirectional shutdown is not yet
--- 218,227 
  .PP
  \fISSL_shutdown()\fR supports both uni- and bidirectional shutdown by its 2 step
  behaviour.
! .Ip
! When the application is the first party to send the \*(L"close notify\*(R" alert, 
SSL_shutdown() will only send the alert and the set the \s-1SSL_SENT_SHUTDOWN\s0 flag 
(so that the session is considered good and will be kept in cache). SSL_shutdown() 
will then return with 0. If a unidirectional shutdown is enough (the underlying 
connection shall be closed anyway), this first call to SSL_shutdown() is sufficient. 
In order to complete the bidirectional shutdown handshake, SSL_shutdown() must be 
called again. The second call will make SSL_shutdown() wait for the peer's \*(L"close 
notify\*(R" shutdown alert. On success, the second call to SSL_shutdown() will return 
with 1.
! .Ip
! If the peer already sent the \*(L"close notify\*(R" alert \fBand\fR it was already 
processed implicitly inside another function (SSL_read(3)), the 
\s-1SSL_RECEIVED_SHUTDOWN\s0 flag is set. SSL_shutdown() will send the \*(L"close 
notify\*(R" alert, set the \s-1SSL_SENT_SHUTDOWN\s0 flag and will immediately return 
with 1. Whether \s-1SSL_RECEIVED_SHUTDOWN\s0 is already set can be checked using the 
SSL_get_shutdown() (see also SSL_set_shutdown(3) call."
  .PP
  It is therefore recommended, to check the return value of \fISSL_shutdown()\fR
  and call \fISSL_shutdown()\fR again, if the bidirectional shutdown is not yet



[no subject]

2002-05-10 Thread Yarbrough, Jeff

Keep getting a fatal error when trying to run the make command for openssl

Here is the error:

testing...
cc -DMONOLITH -I../include -KPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -xtarget=u
ltra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W
-DULTRASPARC -DMD5_ASM
 -c  speed.c
ucbcc: Warning: Option
-YP,:/usr/ucblib:/opt/SUNWspro/WS6U2/bin/../lib:/opt/SUNWspro/WS6U2/bi
n:/usr/ccs/lib:/usr/lib passed to ld, if ld is invoked, ignored otherwise
ucbcc: Warning: "-Xa" redefines compatibility mode from "SunC transition" to
"ANSI"
"/usr/ucbinclude/signal.h", line 49: syntax error before or at: int
"/usr/ucbinclude/signal.h", line 49: warning: undefined or missing type for:
int
*** Error code 2
make: Fatal error: Command failed for target `speed.o'
Current working directory /usr/openssl-0.9.6c/apps
*** Error code 1
make: Fatal error: Command failed for target `apps'
Current working directory /usr/openssl-0.9.6c/test
*** Error code 1
make: Fatal error: Command failed for target `tests'


Please share any insight into this.


Jeffery M. Yarbrough
[EMAIL PROTECTED] 
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #8] EVP_SealFinal declared void while the docu states it returns int

2002-05-10 Thread Dr. Stephen Henson

On Thu, May 09, 2002, Richard Levitte via RT wrote:

> 
> [[EMAIL PROTECTED] - Thu Apr 25 16:16:02 2002]:
> 
> > Is this the expected behaviour ? Either way one must be fixed :)
> > Btw EVP_OpenFinal does exactly what EVP_SealFinal does and adds to
> > this the return value...
> 
> Hmm, I think Steve should answer this one.  Personally, I think this 
> shows a certain inconsistency in the EVP, I see quite a lot of 
> variantion in return types depending on which EVP_*Init, EVP_*Update 
> and EVP_*Final you look at...
> 

Its an omission. It should have been updated when various EVP_*Init
functions were updated to return values.

I'll have a look at it.

Steve.
--
Dr. Stephen Henson  [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Twofish in Openssl

2002-05-10 Thread Satria Bakti (13297096)


Hi,

Now I'm trying to implement Twofish encryption algorithm
into the OpenSSL 0.9.7. I'm trying to implement it the same
way as AES and IDEA implementation.

But, after reading Twofish original sourcecode (taken from
NIST site), I feel that this sourcecode is much more difficult
to be implemented. 

Is there any simpler sourcecode (for OpenSSL implementation) 
or any guidelines that could help me in this Twofish
implementation ? 

Or, is there somebody who has ever done this before ?
Any help would be very appreciated. Thank you.

-- 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #28] minor bug report

2002-05-10 Thread Ivar Smolin via RT


> openssl asn1parse ?
unknown option ?
asn1parse [options]  openssl version
OpenSSL 0.9.6c 21 dec 2001
> cat /etc/debian_version
3.0
> dpkg --print-architecture
i386

-- 
ökul

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]