Hello list,
I'm signing a file using SMIME with 2 signers.
When trying to check the signature with only one of the two signers, it
fails with a "signer certificate not found". Using both signers, it
succeeds.
Is there a way to be able to check the signature with a single signer,
not all of
Hello,
I've built OpenSSL 0.9.8i on a Solaris 9 SPARC system, using a fully
patched Sun Studio 11.
It builds fine, however, «make test» fails (see below).
Version 0.9.8h built on the same system with the same parameters doesn't
fail.
Version 0.9.8i built with Studio 12 on S10 x86 doesn't fail, e
Neetee Pawa a écrit :
> However for me .. the binaries did not work once i compiled in 32 bit
> mode. May be they work for you.
Depending on what your issue was, that reminds me that I use the exact
following to build:
PREFIX=openssl-0.9.8d
export LD_OPTIONS="-R/usr/local/${PREFIX}/lib"
./Config
Andy Harrison a écrit :
> I'm trying to compile with the following options, but it's insisting
> on using the 64 bit version and I can't seem to get around this.
>
> # ./config --install_prefix=/usr/src/OPENSSL --prefix=/usr/local/ssl
> --openssldir=/usr/local/ssl --shared solaris-x86-gcc
> Operat
[EMAIL PROTECTED] a écrit :
> I surely did something wrong, it's ok now.
> Thanks for quick and efficient help.
> Btw it seems that I have seen several people having the same problem.
> Maybe adding a test for the right patches in the configuration step could be
> fine.
Wouldn't be portable. It w
[EMAIL PROTECTED] a écrit :
I'm trying to find the corresponding sparc ones.. I believe I'll get the
answer monday.
They are those:
120760-12 Sun Studio 11: Compiler Common patch for Sun C C++ F77 F95
120761-03 Sun Studio 11: Patch for Performance Analyzer Tools
121015-04 Sun Studio 11: Patch f
[EMAIL PROTECTED] a écrit :
> I don't know. Which patch ?
Those are the latest for Studio 11 on Solaris x86:
120759-10 Sun Studio 11_x86: Sun Compiler Common patch for x86 backend
120762-03 Sun Studio 11_x86: Patch for Performance Analyzer Tools
121016-05 Sun Studio 11_x86: Patch for Sun C_x86 5
Frederic Goudal a écrit :
> I'm in trouble with openlls 0.9.8 on solaris10 : I compile it either
> witch gcc or sun cc (studio11), and when I try an s_client command on
> our web server I got the following error :
Did you patch Studio 11? the original version had issues with OpenSSL
when built wit
CHASTAIN, TIGE (CONTRACTOR) a e'crit :
> I was having problems building OpenSSL 0.9.7k on Solaris 9. The error
> was similar to problems other people have with building it on Solaris 9,
> but not exactly the same.
>
> The error is:
>
> installing fips-1.0...
[snip]
> I thought someone migh
I've seen you fixed your issue, glad I could help.
PATH issues are common on Solaris, where there are many commonly
installed tools. That's why I always keep a very simple one when
building, to be sure what's used for a given source tarball, SunCC, GCC,
make, gmake, and so on.
Marc Girod a écrit :
Marc Girod a écrit :
> I try to build and install on various platforms,
> (Solaris sparcv9, HP-UX, AIX), to a non-standard path,
> for use with subversion.
> A first attempt showed me that svn expected shared libraries,
> so that I try to produce them, first on Solaris.
> My build fails at link tim
Andreas Almroth wrote:
As it is Solaris, use export LD_OPTIONS='-R/usr/local/openssl-0.9.7g/lib
-L/usr/local/openssl-0.9.7g/lib'
The linker will take that into consideration, and if you do a dump -Lv
on the output file, the RUNPATH should be included.
I confirm that that fix is perfect for me.
Andreas Almroth wrote:
> As it is Solaris, use export LD_OPTIONS='-R/usr/local/openssl-0.9.7g/lib
> -L/usr/local/openssl-0.9.7g/lib'
> The linker will take that into consideration, and if you do a dump -Lv
> on the output file, the RUNPATH should be included.
*smacks head*
Ok, I wonder how I manag
prakash babu wrote:
*Solution 1 :*
Create a symbolic link in the system directory for libcrypto.so and
libssl.so
ln -s /usr/local/openssl-0.9.7g/lib/libcrypto.so /usr/lib/libcrypto.so
ln -s /usr/local/openssl-0.9.7g/lib/libssl.so /usr/lib/libssl.so
Evil. This is a sure road to troubles at som
Hello all,
I've got a relatively minor problem with OpenSSL linking, it may be a
flaw in the configure script, or just me not finding the right option.
Here is is: I want to build OpenSSL with an integrated linker runpath,
so I don't need LD_LIBRARY_PATH or crle hacks.
Since some OpenSSL bi
I think this is an install problem, but I'm not familiar enough with the
way *.pod are converted to man to find out where it comes from.
On installing 0.9.7c, the file EVP_BytesToKey.3 is a link to itself.
# ls -l /opt/openssl-0.9.7c/ssl/man/man3/EVP_BytesToKey.3
lrwxrwxrwx 1 root other
Victor wrote:
Suggestion - add /usr/ccs/bin to your path instead of putting it on
the configure line. Also, I'd go with the default "as" and "ld" - not
ccs/bin. But this likely isn't your problem, just a suggestion.
I used it because that's what sunfreeware did too, doesn't seem to have
any af
Victor wrote:
Yes, it does exist. And yes, setting LD_LIBRARY_PATH does fix things. It
wasn't set. It does seem that openssl was clear of any wrong doing, I am
sorry to have posted offtopic. But you guys have been really helpful.
Technically, the -L arguments should have done what LD_LIBRARY_PA
Louis LeBlanc wrote:
Typically, these trojans are dialers or spyware of some sort that
install themselves when some unsuspecting person opens them. If you
ever have one installed on you, you'll very likely start getting
random popups to some Russian porn site. These trojans are usually
base64 enc
Wayne Thomas wrote:
I am attempting to compile openssl-0.9.7 on my Solaris 8 Sun Blade 100
with simply ./config and make. The following error occurs:
"/usr/ucbinclude/signal.h", line 49: syntax error before or at: int
"/usr/ucbinclude/signal.h", line 49: warning: undefined or missing type
This
20 matches
Mail list logo
