The collected works of squeen - Page 6

I may have gotten confused since I haven't used VNC for a while, but I believe x2vnc will just share keyboard & mouse, while using vncclient (from tightvnc) to log into a machine running a vncserver will give you the other machine's desktop-in-a-window.

Sorry if I have it wrong.
Tut-tut! Bad gcc/C++ habits!
cc-1098 cc: ERROR File = test_quad.c, Line = 7
An array cannot have elements of the indicated type.

void matrix_mult(long double A[][], long double B[][], long double C[][], int n);
^

cc-1098 cc: ERROR File = test_quad.c, Line = 7
An array cannot have elements of the indicated type.

void matrix_mult(long double A[][], long double B[][], long double C[][], int n);
^

cc-1098 cc: ERROR File = test_quad.c, Line = 7
An array cannot have elements of the indicated type.

void matrix_mult(long double A[][], long double B[][], long double C[][], int n);
^

cc-1098 cc: ERROR File = test_quad.c, Line = 8
An array cannot have elements of the indicated type.

void matrix_print(long double M[][], FILE * nout, int n);
^

cc-1098 cc: ERROR File = test_quad.c, Line = 9
An array cannot have elements of the indicated type.

void matrix_rand(long double M[][], int n);
^

cc-1241 cc: ERROR File = test_quad.c, Line = 27
A declaration cannot appear after an executable statement in a block.

long double A[MAX_DIM][MAX_DIM];
^

cc-1241 cc: ERROR File = test_quad.c, Line = 28
A declaration cannot appear after an executable statement in a block.

long double B[MAX_DIM][MAX_DIM];
^

cc-1241 cc: ERROR File = test_quad.c, Line = 29
A declaration cannot appear after an executable statement in a block.

long double C[MAX_DIM][MAX_DIM];
^

cc-1551 cc: WARNING File = test_quad.c, Line = 34
The variable "t1" is used before its value is set.

t1 += (double)tp.tv_sec+(1.e-6)*tp.tv_usec;
^

cc-1551 cc: WARNING File = test_quad.c, Line = 37
The variable "t2" is used before its value is set.

t2 += (double)tp.tv_sec+(1.e-6)*tp.tv_usec;
^

cc-1552 cc: WARNING File = test_quad.c, Line = 14
The variable "rtn" is set but never used.

int rtn, i;
^

cc-1174 cc: WARNING File = test_quad.c, Line = 14
The variable "i" was declared but never referenced.

int rtn, i;



Running modified code (below) on 1 1Ghz R16K with MIPSpro C 7.4.4m, I get

~:cc -64 -IPA -Ofast=IP30 test_quad.c -o test_quad
cc-1178 cc: WARNING File = test_quad.c, Line = 34
Argument is incompatible with the corresponding format string conversion.

printf("size of long double: %d\n", sizeof(long double));
^

~:test_quad
Using default value, n = 128
size of long double: 16

Elapsed time to multiply two matrices of order 128: 0.242758


More precision, but slower than the Dell-box. Would be interesting to se how the IRIX scientific lib (SCSL) would handle things.

The poor performance of your previous test on the O2K would be gcc?


And the more C/IRIX friendly code:

Code: Select all

#include <math.h>
#include <stdio.h>
#include <sys/time.h>
#include <stdlib.h>

#define MAX_DIM 256
void matrix_mult(long double A[][MAX_DIM], long double B[][MAX_DIM], long double C[][MAX_DIM], int n);
void matrix_print(long double M[][MAX_DIM], FILE * nout, int n);
void matrix_rand(long double M[][MAX_DIM], int n);

int main(int argc, char ** argv){
int n;
double t1=0.0, t2=0.0, elapsed;
timespec_t tp[2];
FILE *nout;
long double A[MAX_DIM][MAX_DIM];
long double B[MAX_DIM][MAX_DIM];
long double C[MAX_DIM][MAX_DIM];

memset( C, 0, MAX_DIM*MAX_DIM*sizeof(long double) );
nout = fopen("/dev/null", "r+");
if ( !nout ) {
fprintf(stderr,"open failed\n");
exit(-1);
}

n = 128; /* default order of matrix */
if(argc < 2)
printf("Using default value, n = 128\n");
else{
n = atoi(argv[1]);
printf("Using n = %d\n", n);
}

printf("size of long double: %d\n", sizeof(long double));

matrix_rand(A, n);
matrix_rand(B, n);
clock_gettime(CLOCK_SGI_CYCLE, &tp[0]);
matrix_mult(A, B, C, n);
clock_gettime(CLOCK_SGI_CYCLE, &tp[1]);

t1 += (double)tp[0].tv_sec+(1.e-9)*tp[0].tv_nsec;
t2 += (double)tp[1].tv_sec+(1.e-9)*tp[1].tv_nsec;
matrix_print(C, nout, n);

elapsed = t2 -t1;
printf("\nElapsed time to multiply two matrices of order %d: %f\n", n, elapsed);

return(0);
}
/*****************************************************************************/
void matrix_mult(long double A[][MAX_DIM], long double B[][MAX_DIM], long double C[][MAX_DIM], int n){
int i, j, k;
for(i = 0; i < n; i++)
for(j = 0; j < n; j++)
for(k = 0; k < n; k++)
C[i][j] +=  A[i][k]*B[k][j];
}
/*****************************************************************************/
void matrix_print(long double M[][MAX_DIM], FILE * nout, int n){
int i, j;
for(i = 0; i < n; i++){
for(j = 0; j < n; j++){
fprintf(nout, "%5.5Lf  ", M[i][j]);
}
}
}
/*****************************************************************************/
void matrix_rand(long double M[][MAX_DIM], int n){
int i, j;
for(i = 0; i < n; i++)
for(j = 0; j < n; j++)
M[i][j] = (double)rand()/12.3;
}
Yup. I originally ran it on the Octane (0.437848 sec). The Tezro run time was the same, with IP35.

Thanks neko, good catch.
OK, The same machine (R16K) that ran 0.24 sec with MIPSpro ran 7.37 secs with gcc (-O3), roughly 30 times slower .
jan-jaap wrote: Algorithm optimization rules -- you can't beat that with compiler switches!


Amen brother!

BTW what clock speed on the Indigo2?
Hmm...looks like blas3 (man INTRO_BLAS3) doesn't support quad precision, just single (SGEMM) and double (DGEMM). Still, a double precision test might be fun.
Belive it or not, it does come up at times in engineering. We are looking at advanced spacecraft formations thousands of kilometers apart with nanometer precision (1e6+1e9 = 1e15) which is right at the tail end of double precision.
Outstanding jan-japp!

I had to make the following code changes to get it to run on the Tezro. I guess you are using the (older?) CBLAS routines as opposed to the SCSL C interface.
man INTRO_BLAS3 wrote: NOTE: SCSL supports two different C interfaces to the BLAS:

* The C interface described in this man page and in individual BLAS man
pages follows the same conventions used for the C interface to the
SCSL signal processing library.

* SCSL also supports the C interface to the legacy BLAS set forth by
the BLAS Technical Forum. This interface supports row-major storage
of multidimensional arrays; see INTRO_CBLAS(3S) for details.



Here's the diff output:

Code: Select all

~:diff test_double.c test_double.orig.c
5,6c5,6
< /* #include <cblas.h> */
< #include <scsl_blas.h>
---
> #include <cblas.h>
>
42c42
<     dgemm("N", "N", n, n, n, alpha, &a[0], n, &b[0], n, beta, &c[0], n);
---
>     dgemm(NoTranspose, NoTranspose, n, n, n, alpha, &a[0], n, &b[0], n, beta, &c[0], n);


and the compile line changes (for me) to:
cc -fullwarn -O3 -Ofast=IP35 -IPA -o test_double test_double.c -lscs -lftn


The result is
test_double
Using default value, n = 128

Elapsed time to multiply two matrices of order 128: 0.003320


Now, to be fair I re-ran the origin test_quad in "double" mode (replace long double -> double ) and got:

~:cc -fullwarn -O3 -Ofast=IP35 -IPA -o test_quad-double test_quad-double.c
~:test_quad-double Using default value, n = 128
size of double: 8

Elapsed time to multiply two matrices of order 128: 0.002489


which was faster (!) than the blas routine on my machine. Naive matrix mult not so bad for general matrix types?

Another test in "64 bit mode"

cc -64 -fullwarn -O3 -Ofast=IP35 -IPA -o test_double test_double.c -lscs -lftn

test_double
Using default value, n = 128

Elapsed time to multiply two matrices of order 128: 0.003326


no change from -n32. But switch in the multiprocessor version of SCSL lib and

cc -n32 -fullwarn -O3 -Ofast=IP35 -IPA -o test_double test_double.c -lscs_mp -lftn
test_double
Using default value, n = 128

Elapsed time to multiply two matrices of order 128: 0.045474


which is slower on the small matrix, so let's try the 1024x1024.

cc -n32 -fullwarn -O3 -Ofast=IP35 -IPA -o test_double test_double.c -lscs -lftn
Using default value, n = 1024

Elapsed time to multiply two matrices of order 1024: 1.320950

cc -n32 -fullwarn -O3 -Ofast=IP35 -IPA -o test_double test_double.c -lscs_mp -lftn

test_double
Using default value, n = 1024

Elapsed time to multiply two matrices of order 1024: 0.941582


as expected on larger problems the multiprocessing starts to pay off.

The message that keeps getting shoved into my face again and again with coding for performance (math or graphics) is "Know your hardware, know your problem." and find the fast-path for your situation. As an addendum I'd add that this implies high-performance cross-platform code seems to be a pipe dream.
I deleted the other version of this post under the "SGI Chat" forum.
Thanks Arti77. Got to get the lastest into Nekoware, but I've just been swamped lately... :(
@edefault : I have the following line in my .sgisession (all one line)

Code: Select all

xset +fp /usr/freeware/share/emacs/fonts & /usr/nekoware/bin/iconbar & /usr/nekoware/bin/xscreensaver-command -exit; /usr/nekoware/bin/xscreensaver -nosplash


which avoids (I believe) the problem you're experiencing with .loginrc.

@stuart : I agree the dual channel needs a bit more work. I'm sure getting it to launch on channel 1 can be done fairly easily, and I'll look into it next week. What you suggest about display boundry smarts is also a great idea - now that I've got the channel size data using the SGI video extension ( v0.8 ) it should not be too serious an undertaking. I'll put it on the todo list.

And thanks to you both for the feedback. :)
I think that neko_scribus was built against old libs and requires a rebuild.
If you don't use icons, can you display a single graphic image of your own choosing?
I just updated my Nekoware (after installing a bigger HDD), and with new software like blender, bionic, imagemagick and a working (thanks neko!) firefox, if feels just like the good old days when I feverishly download the lastest IRIX OS releases and freeware (and didn't have to do any of the heavy lifting myself :oops: ).
All-in-all, Not too shabby. :)
OK. I'm going to continue to champion beta practices. When a major componet like GTK+, Perl, readline etc. gets updated and has the potential to massive disable nekoware, there needs to be a buffer---that's /beta. For top level apps with no child dependancies, it probably is less useful.

As for feeling disappointed about feedback, for the most part we port apps to meet a personal need and/or scratch an itch. That won't neccessarily translate to the community in general...well at least not immediately. But sometimes, maybe a year or so later, you will have made somebody's day/week/month in a big way. Let's hope's he/she takes the time to say thank you. My feeling is that most folks around here do. But, now that most the "core" apps have been ported, the odd-bits are less likely to win you immediate praise---which is unfortunate, because schleusel you do a fantastic job and we all benefit greatly from your hard work.
Neko, you shouldn't have to bear the burden for sure. Instead, the packager should razz the community "SOMEONE PLEASE TEST MY APP", not, "Neko, why haven't you moved my app out of beta?". I don't really see the issue with apps lingering in beta for awhile if no one tests them., but that just suits my needs. Again, for the no deps, we can skip this step. But, I really depend on IRIX and Nekoware every day and instability is a major bane for me. For a casual (dare I say Linux) mentality, maybe new=better works. OK, that was a cheap shot... :)
joerg wrote: I hope you got something wrong.

Yes I did. I meant to include you with schleusel, neko (and others) in my praise for the prolific and excellent work you have done. :)

I see your point on stale beta dependancies, but all that is required to move from beta to current is only one other member to validate it works OK on their system. Too often our build systems can accumulate items that are missing from the packages. It's just a check on that.

Btw:
If i would like so see something in /current i would place it there.


Sorry, I don't follow what you are saying here.

Oh well...I see value in a /beta-staging, but also sense that Neko would rather do without the added responsibility. I totally understand that, and only want to deflect that responsibility to the developers and community members instead.
I put the dvdrtools package in and am more than happy to see it become obsolete. Nice work, schleusel! I'll try the CD-R capability tomorrow morning.

Thank you.
Not wanting to miss out on the renaissance in nekoware upgrades I put together the following 2-12's

neko_glib-2.12.2
neko_gimp-2.2.12

The glib rebuild fixes my long standing problem with GIMP (ie. I couldn't load any files with a memory error, in fact I couldn't even build GIMP until I replaced glib).
They're in /beta. Please give them a whirl. :)
nekonoko wrote:
Cool! Only issue I can see off the bat is that none of the prereqs are taken into account for the GIMP plugins in /usr/nekoware/lib/gimp/2.0/* - let's take one at random:

Code:
[Mai:gimp/2.0/plug-ins] neko 16# ldd ./tiff
libgimpui-2.0.so.1  =>   /usr/nekoware/lib/libgimpui-2.0.so.1
libgimp-2.0.so.1  =>     /usr/nekoware/lib/libgimp-2.0.so.1
libgimpwidgets-2.0.so.1  =>      /usr/nekoware/lib/libgimpwidgets-2.0.so.1
libgimpmodule-2.0.so.1  =>       /usr/nekoware/lib/libgimpmodule-2.0.so.1
libgimpcolor-2.0.so.1  =>        /usr/nekoware/lib/libgimpcolor-2.0.so.1
libgimpbase-2.0.so.1  =>         /usr/nekoware/lib/libgimpbase-2.0.so.1
libtiff.so.3  =>         /usr/nekoware/lib/libtiff.so.3
libjpeg.so  =>   /usr/nekoware/lib/libjpeg.so
libgtk-x11-2.0.so.1  =>  /usr/nekoware/lib/libgtk-x11-2.0.so.1
libgdk-x11-2.0.so.1  =>  /usr/nekoware/lib/libgdk-x11-2.0.so.1
libatk-1.0.so.1  =>      /usr/nekoware/lib/libatk-1.0.so.1
libgdk_pixbuf-2.0.so.1  =>       /usr/nekoware/lib/libgdk_pixbuf-2.0.so.1
libpangocairo-1.0.so.1  =>       /usr/nekoware/lib/libpangocairo-1.0.so.1
libpangoft2-1.0.so.1  =>         /usr/nekoware/lib/libpangoft2-1.0.so.1
libpango-1.0.so.1  =>    /usr/nekoware/lib/libpango-1.0.so.1
libcairo.so.3  =>        /usr/nekoware/lib/libcairo.so.3
libpixman.so.1  =>       /usr/nekoware/lib/libpixman.so.1
libXrender.so.1  =>      /usr/nekoware/lib/libXrender.so.1
libX11.so.1  =>  /usr/lib32/libX11.so.1
libpng12.so.0  =>        /usr/nekoware/lib/libpng12.so.0
libglitz.so.2  =>        /usr/nekoware/lib/libglitz.so.2
libfontconfig.so.2  =>   /usr/nekoware/lib/libfontconfig.so.2
libexpat.so.1  =>        /usr/nekoware/lib/libexpat.so.1
libfreetype.so.7  =>     /usr/nekoware/lib/libfreetype.so.7
libz.so  =>      /usr/nekoware/lib/libz.so
libm.so  =>      /usr/lib32/libm.so
libgobject-2.0.so.1  =>  /usr/nekoware/lib/libgobject-2.0.so.1
libgmodule-2.0.so.1  =>  /usr/nekoware/lib/libgmodule-2.0.so.1
libglib-2.0.so.1  =>     /usr/nekoware/lib/libglib-2.0.so.1
libintl.so.4  =>         /usr/nekoware/lib/libintl.so.4
libiconv.so.3  =>        /usr/nekoware/lib/libiconv.so.3
libc.so.1  =>    /usr/lib32/libc.so.1
libCsup.so  =>   /usr/lib32/libCsup.so
libC.so.2  =>    /usr/lib32/libC.so.2
libCio.so.1  =>  /usr/lib32/libCio.so.1
libXext.so  =>   /usr/lib32/libXext.so


Granted, some of those are recursive but there's a lot more there than the package is allowing for at present ;)


Believe it or not, with maybe the exception of pixmap/glitz, all those are in or prereq's of neko_gtk. (BTW, the last packing had no prereq's listed :) )
Perhaps other plugins are different. I'll take a look next week.

EDIT:

I resisted listing perl/python since the package will function without plugins or scripting. Again, same as last 4 versions. Also, the self dependacies is something I also had never added before and purposly left out in the first nekoware issue (but thought I had added in this case...hmmm...probably forgot the apply button inn swpkg!).
thunng8 wrote:

That's strange, I never got the memory error before.

Just installed glib-2.12.2 and am now get the memory error (cannot load any files). I also get the memory error in foetz's gimp-2.2.12 build with this new glib.

Reverting back to glib-2.8.4 fixed the problems.


I was wondering why more folks weren't complaining about the GIMP being broken. I have 2 systems (an Octane and Tezro) runing 6.5.29 that had the same memory error problem. What version of OS are you using? Again, I'm wondering if a serious incompatability exists!?! Oh, also I'm compiling with 7.4.4m. Anyone else with and experience to share?

@joerg: About prereqs: If an app as a prereq of GTK like the GIMP does, I do not feel it is a good idea to add all of GTK's prereq's to the GIMP. That's the way all the original nekoware wer packaged.
On the GIMP/GTK issue. I read the nice write up on rqs that chervarium wrote and that combined with some checks stuart had me do with gmemusage and GIMP I think it's pretty likely close to target. I want to make sure I understand the issue correctly so I can "rectify" whatever machine is in a non-standard state. Is it the opinion of others that the packages are not and cannot be twisted, just the install system(s)?

Edit: Another thought...could the rqs explain why I couldn't even build the GIMP? (damn, I wished I'd recorded the error message).

Joerg wrote:
All libs which are shown from a ldd foo.so have to be in the prereqs. No more and no less. Thats the way how sgis swpkg works and i hope the most of our packages used it in this ways.


Taking a hard line, eh? I think I'd best wait a bit before responding.
Placed neko_dia-0.95 into /beta. It has whiter's new neko_perl_xml dependancy.

Still looking into the rqs issue...as well as xft.
neko_glib-2.12.2 (beta) fixed neko_mozilla-1.8a5 on my system! Hello AA fonts (again). :D
Do you know what would be awesome...a wrapper to the "install" command that (when invoked by gmake install) would autiomagically create the file databased used by inst. I know it would have issues (i.e. Makefiles that by pass install and do cp/mv commands instead), but wouldn't that be awesome---if install actually installed packages in a managable database at the end of the build. Tardist building would be a no brainer.
schleusel wrote:
I keep being disturbed by the sheer slowness of gtk2 on irix, something is just wrong there. QT blows it away at the same level of questionable eye candy :-|


You are right there. If our gtk2+ is using cairo/glitz which relies on openGL for rendering instead of the software in libXrender, the silly thing should be flying on VPros which have awesome 2D capabilities---blowing away even top of the line nVidia cards on things like pixel readback. I honestly believe digging into the code a bit could dramtically speed up gtk (unless it's some other software inefficiency).
Cool Whiter. I'll give it a spin if you can ressurect it (although I was more talking about just building a data base as opposed to actually relocating files).

Regarding cairo/glitz....definately Linux targeted. Who knows if it makes good use of things on IRIX. I've down loaded it and will look at the code.
In /beta : For those folks interest in playing with the GNU Flash player + a repackage to eliminate glib erros in dia.


neko_gtkglext-1.2.0
neko_gnash-cvs20060823
neko_dia-0.95


The plugin for gnash is in /usr/nekoware/lib/libgnashplugin.so. Link it to your $HOME/.mozilla/plugins directory to get it recognized. The caveats are that SDL_mixer sounds is broken, its GTK2 based so neko_firefox doesn't like it, and neko_mozilla won't execute it. So basically as a plugin it is useless until some brave soul fixes it. The command line player (/usr/nekoware/bin/gnash) works. Probably should stay in beta limbo until the issues are resolved. A build of Gstreamer would probably fix the sound.

EDIT : I plugged dia-0.95. I've got more packaging (lib) errors.
whiter wrote:
Code:
_RLDN32_LIST=/usr/people/whiter/nekodev/nekodev.so:DEFAULT
/tmp/blablabla


It's fun :)

Now.... Squeen... if you feel like helping out with developing this further, that would be great. I'm not such a brilliant c coder :)


Didn't know you could force everthing through a single dynamic lib? I have spoofed lib functions before by forcing my (similarly named) lib to appear in a directory earlier on the RLD_ ROOT doing something and then using dlopen to get and execute the proper function. What about statically link apps?---where and what function calls are you catching?--the shell? Yeah, I'd like to play with it.... :)

Isn't there a restriction on rld'ing root?
I don't know if you can make a general wrapper function since dlopen needs a specific prototype and library in order to find the spoffed function. All you can do is target a certain number of syscalls and make a specifc wrapper for each...I think. There is a general problem IIRC with passing varags to another varg function (e.g. printf), which might be lurking out there. Hmm....things like mkdir() are C functions, but how is cp implimented...by read() and write() in the shell? Maybe we look just at gmake and see if it uses the system() command to send it's instructions down the pipe. In which case we just intercept system() and parse the commands for one's we care about---hell for that matter we've got the source to gmake, why not just patch it in neko_gmake to make a database copy of all commands executed as root or when a specific environment varaiable is set? Yeah, why come in through the back-door when the front-door was left open?

Am I re-inventing your wheel? Have you got this all working already?
On line #1987 of job.c in (g)make-3.81 is a function called exec_command might be fun to just put a print statement in there that echoed the command string.
I just browsed *all* of the glitz source. There's hardly anything in there. It's all about resolving the cross platform OpenGL problem (do I have pbuffers? do I have framebuffer objects? do I have shaders? do I have multisample?) and just a tiny bit of rendering of rectangles and what not. Maybe I'm missing the hidden elegance of the design. I'll compile it and cairo next week and try to figure out if it's worth tweeking for IRIX. Hard to believe this is "The Future of Desktop 2D Rendering" to quote that Linux fanatic at Neko's link (above) when you could have do it on an Indy 15 years ago. Oh the hype...

Along similar lines, Mark Kilgard (when he was at SGI in the early '90's) proposed and tinkered with an OpenGL based desktop. 10 years later the glitz folks are working on Xgl. Hmm...
nekonoko wrote:
squeen wrote: I'll try and repackage neko_subversion with the lastest release using both a new snvserve bin location, neko_svnserve chkconfig flag, and rc2.d startup script if no one minds.


Did you ever get that pulled together? Would be an interesting addition!

Forgot all about it. I'll put it back on my to do list.
On MIPS processor I believe PIC is the default and only way to build shared libs (same on PowerPC).
GeneratriX wrote:
neko_gimp-2.2.12.tardist (which bombs out as soon I open an image)
neko_mozilla-1.8a5.tardist (which bombs out randomly)

BTW: ...I also have neko_dia-0.95.tardist installed, which seems to work just fine... so, is there any major bug of which I was not awared of, I mean, it was removed from nekoware?


What were the error messages on gimp & mozilla. I bet it's the same old glib memory mangling...really need to get to the bottom of that once and for all.

I'm glad to hear dia-0.95 was working for you. It starting throw glib memory errors as well until I recompiled it against the newer version. I'll try to repackage it next week. Unfortunately, I'll be traveling a bit until then.
Saw it. Good info. I'll try to set up some experiments (with known failure cases).
A nice solid foundation Neko! I'll pull them down and give then a test run. Thanks!
No. But it sounds worth checking out. Thanks.
schleusel wrote: uploaded to beta:

neko_dvdauthor-0.6.11.tardist - command line DVD authoring tools
neko_libdvdread-0.9.6.tardist - library for reading DVD-video images
neko_mjpegtools-1.8.0.tardist - tools for MJPEG/MPEG capture/editing/compression
neko_mpgtx-1.3.tardist - command line MPEG audio/video toolbox
neko_dvdplusrw_tools-6.1.tardist DVD mastering tools (does not interfere with neko_cdrtools. It mereley adds some additional tools)

neko_dvdstyler-1.4.tardist wxwindows based GUI frontend for the dirty dozen ;-)

I couldn't test it much yet. Creating a very simple project and letting it create the DVD structures and image of it at least looked promising though..

DVDstyler is built against wxgtk. I was hoping to be able to build it against wxmotif but that didn't work out due to apparently missing drag and drop support in wxmotif :-(


I can't wait to try the whole suite. Thanks!
Quote:
Description
-------------------------------------------------------------------------------------
OpenSSL versions 0.9.7j and prior and 0.9.8b and prior contain a vulnerability that could allow an unauthenticated, remote attacker to successfully pass a forged x.509 certificate.

The vulnerability could allow an unauthenticated, remote attacker to pass a forged Public-Key Cryptography Standards (PKCS)#1 Version 1.5 signature when signed by a certain type of RSA key. An attacker may be able to exploit this vulnerability to utilize a forged signature to gain access to certificate-protected resources.

OpenSSL confirmed this vulnerability in a security advisory and released updated versions.

Impact
-------------------------------------------------------------------------------------
An unauthenticated, remote attacker could exploit this vulnerability to gain access to certificate protected resources. This could result in the attacker disclosing protected information or taking actions as the user within the forged certificate.

Warning Indicators
-------------------------------------------------------------------------------------
OpenSSL versions 0.9.7j and prior and 0.9.8b and prior are vulnerable.

Technical Information
-------------------------------------------------------------------------------------
The vulnerability is due to an error when validating padding of PKCS #1 v1.5 signatures. If a RSA key with exponent 3 is used, an attacker may be able to forge a PKCS #1 v1.5 signature signed by that key. Because OpenSSL fails to check for excess data in the RSA exponentiation result of the signature, the certificate may inadvertently be marked as valid.

Safeguards
-------------------------------------------------------------------------------------
Administrators are advised to upgrade to the appropriate version.

Administrators are advised to utilize certificates as part of a two-factor authentication system.

Administrators may consider restricting access to certificate-protected resources to trusted users through the use of a VPN or other remote access technology that is not affected.