Re: Bank Leumi site lack of adherence to web standards
On Sat, 2006-04-08 at 20:21 +0300, Dov Grobgeld wrote: > Sigh... So it means that I still have to reboot into Windows and use > Internet Explorer whenever I want to access my Bank Account. Are other > banks better? Seems that we'll have to wait until some black hat breaks into Israeli bank accounts via an IE vulnerability. Then have the victims organize a massive group lawsuit, which includes also punitive damages, on grounds that the banks did not provide for a way to securely access the Web sites in question. Seems also that the above scenario will have to happen, because the banks (except perhaps for Bank Hapoalim) do not listen to warnings about this. May I suggest to move further discussion of this topic to [EMAIL PROTECTED] --- Omer -- MS-Windows is the Pal-Kal of the PC world. My own blog is at http://tddpirate.livejournal.com/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Missing from the thread? (was: Re: Shared Object, ID yourself)
On Sun, 2006-04-09 at 01:50 +0300, Michael Vasiliev wrote: > On Saturday April 8 2006 13:01, Oleg Goldshmidt wrote: > [information which I found very useful] > > This has to be the most educational thread for me that I saw on the list in > years. Orna, Oleg, if you are going to discuss this further, don't forget to > CC yours truly ;) Oh, now I realize what was missing from the thread. Gems like mentioning unfavorably the intelligence of other contributors to the thread, miscellaneous politically incorrect expressions, hot flamewars, religious arguments. Especially were missing general condemnations, without understanding the context, of usage of non-favorite programming tools. Even curses in pig Latin were absent. Symbolic link names suck! MD5 rulez! :-) -- Jara Cimrman. A name to remember. My own blog is at http://tddpirate.livejournal.com/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Shared Object, ID yourself
On Saturday April 8 2006 13:01, Oleg Goldshmidt wrote: [information which I found very useful] This has to be the most educational thread for me that I saw on the list in years. Orna, Oleg, if you are going to discuss this further, don't forget to CC yours truly ;) -- Sincerely Yours, Michael Vasiliev Confidence is the feeling you have before you understand the situation. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Bank Leumi site lack of adherence to web standards
On Sat April 8 2006 20:21, Dov Grobgeld wrote: > Sigh... So it means that I still have to reboot into Windows and use > Internet Explorer whenever I want to access my Bank Account. Are other > banks better? Poalim's site is slightly better, i.e. the site mostly works under FireFox, barring several bugs here and there ( hebrew menus are reversed until the page is refreshed, DHTML menus on Poalim's main site are shown by FireFox in an extremely broken way etc). -- Regards, Alex Chudnovsky e-mail : [EMAIL PROTECTED] ICQ : 35559910 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Bank Leumi site lack of adherence to web standards
Hello, Since there has been some talk on this list about various not working with Linux, I thought I would report on a phone conversation that I had last night with the technical support of the Bank Leumi web site. I had written in in their customer feedback form and told complained that the site is not standard complient, does not work with Firefox, and that their use of JavaScript probably made it non-accessible. They actually called me up yesterday, and the guy I spoke to acknowledged that that is the case, that they are aware of it, and that they have no immediate plans of mending it. They are only doing small changes and improvements to the web site code. He said that he R&D guys would be happy to rewrite the site as the current site is not accessible to Macintosh users nor handheld computers either. But there is no support for funding any for any such changes in Bank Leumi. My mentioning of Linux, he said was the second complaint about that Linux, he had ever heard... Regarding accessibility, he said that that would be a concern for them *only* when that was required by legislation. Sigh... So it means that I still have to reboot into Windows and use Internet Explorer whenever I want to access my Bank Account. Are other banks better? Regards, Dov To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Shared Object, ID yourself
On Sat, 8 Apr 2006, Oleg Goldshmidt wrote: > Date: Sat, 08 Apr 2006 12:56:34 +0300 > From: Oleg Goldshmidt <[EMAIL PROTECTED]> > Reply-To: linux-il@linux.org.il > To: Orna Agmon <[EMAIL PROTECTED]> > Subject: Re: Shared Object, ID yourself > > Orna Agmon <[EMAIL PROTECTED]> writes: > > > First, clearing some things: I do not expect the so and my code to > > be compiled using the same compiler (they are even different > > languages). I do expect the shared library which implements the > > language internals > > Well, I obviously don't know what it implements, but if it implements > "language internals" and is used by the compiler itself during > compilation, then my previous posting is irrelevant, as I noted there. > > I am still assuming that it is *your* code that uses the library, not > the compiler. > > > I do not see anything wrong yet, I try to make sure things always > > work. > > A fresh approach indeed... ;-) [I am sure you know how much in favor > of this approach I am.] > > > The things I worry about are not regarding the location of functions > > in the shared object, but rather prototypes. Fortran compilers do > > not tend to verify prototypes, and it cannot get worse than PG > > fortran. (Pg fortran programs are linked with the PG C shared > > library). BTW, g77 verifies prototypes if the definition of the > > function is in the same file as its usage, and gfortran (gcc 4.0.1) > > compares different usages. The whole notion of declaring prototypes > > is new to fortran. > > And indeed, I am old enough to have never used them. However, I think > I do have the basic idea, and as you mention with regards to > g77/gfortran the prototype must be available within the same > compilation unit as the usage (no different from C). This means (to > me, at least), that if you are concerned about prototypes then, > besides the .so, you need an .inc file decraring the prototypes, or at > least documentation that comes with the library and describes its > interface. Without that, you would not be able to use the library at > all, would you? As long as you use the library facilities correctly in > your code, the compiler should not be a problem with prototypes or > without (assuming it is internally correct). > I have the book that comes with the PG compiler, it does not specify headers. I also failed to find headers in the man pages installed with the compiler. The only place where headers are found is in books describing the language, and those, as I said, vary so much with time, that functions just stop existing. > > I have already encountered a change in the number of variables > > passed to a function between different fortran compilers. > > What do you mean? That a Fortran compiler actually passes internal > variables to the internal representation of a function, and the number > and/or signature of these internal variables varies with the compiler > version, breaking compatibility between code compiled with different > versions of the compiler? Then you are in trouble indeed, and that > trouble is *not* confined to a specific library. > The compiler somehow enforces certain headers. For example, a function called "time" which got compiled in one compiler with one integer variable, and in another with no variables. I do not see any connection between this function and time (2). In other cases, where only my functions are involved, indeed the prototype validation works only for the same compilation unit. So the conclusion I draw is that the compiler verifies prototypes (outside the compilation unit) only for built-in functions. > > dynamically link with a shared library which was built according to > > different APIs, who will warn me and break? > > Linker, in general. I don't see how the compiler can warn you of that > - it's none of its business. When you compile a unit, the compiler > simply is not aware of the other units or libraries you are going to > link with, so it cannot tell you whether your call to foo() is correct > or not. If you provide a prototype, it can check against that > prototype. It still has no idea whether another unit's implementation > corresponds to the prototype or not. I have only heard of, never seen, prototype forward declarations in Fortran. In all the code I have seen so far, the prototype is the actual declaration of the function/subroutine. Indeed, a common problem with Fortran is that it is willing to accept (in most compilers, even within the same compilation unit) a call to a function with a different number of arguments than the way it was defined. The outcome is not elegant like C++ or matlab. The rest of the varibles do not get a default value. If you supply too many (or too long - usually there is no type checking at all), you run over the stack. Supply too little or too short, and you will have uninitialized values. This is even worse than it sounds, since in traditional fortran variables are passed by reference, so you will find yourself writing to a ra
Re: Shared Object, ID yourself
Orna Agmon <[EMAIL PROTECTED]> writes:
> First, clearing some things: I do not expect the so and my code to
> be compiled using the same compiler (they are even different
> languages). I do expect the shared library which implements the
> language internals
Well, I obviously don't know what it implements, but if it implements
"language internals" and is used by the compiler itself during
compilation, then my previous posting is irrelevant, as I noted there.
I am still assuming that it is *your* code that uses the library, not
the compiler.
> I do not see anything wrong yet, I try to make sure things always
> work.
A fresh approach indeed... ;-) [I am sure you know how much in favor
of this approach I am.]
> The things I worry about are not regarding the location of functions
> in the shared object, but rather prototypes. Fortran compilers do
> not tend to verify prototypes, and it cannot get worse than PG
> fortran. (Pg fortran programs are linked with the PG C shared
> library). BTW, g77 verifies prototypes if the definition of the
> function is in the same file as its usage, and gfortran (gcc 4.0.1)
> compares different usages. The whole notion of declaring prototypes
> is new to fortran.
And indeed, I am old enough to have never used them. However, I think
I do have the basic idea, and as you mention with regards to
g77/gfortran the prototype must be available within the same
compilation unit as the usage (no different from C). This means (to
me, at least), that if you are concerned about prototypes then,
besides the .so, you need an .inc file decraring the prototypes, or at
least documentation that comes with the library and describes its
interface. Without that, you would not be able to use the library at
all, would you? As long as you use the library facilities correctly in
your code, the compiler should not be a problem with prototypes or
without (assuming it is internally correct).
> I have already encountered a change in the number of variables
> passed to a function between different fortran compilers.
What do you mean? That a Fortran compiler actually passes internal
variables to the internal representation of a function, and the number
and/or signature of these internal variables varies with the compiler
version, breaking compatibility between code compiled with different
versions of the compiler? Then you are in trouble indeed, and that
trouble is *not* confined to a specific library.
> dynamically link with a shared library which was built according to
> different APIs, who will warn me and break?
Linker, in general. I don't see how the compiler can warn you of that
- it's none of its business. When you compile a unit, the compiler
simply is not aware of the other units or libraries you are going to
link with, so it cannot tell you whether your call to foo() is correct
or not. If you provide a prototype, it can check against that
prototype. It still has no idea whether another unit's implementation
corresponds to the prototype or not.
> Another example: I saw two compilers (I am not sure they were by the
> same company) where in one system (as in system("rm -rf my_file"))
> was a function, and in the other - a subroutine (return value
> changed between int and void), meaning the same code could not be
> compiled in both compilers: in fortran, this means changing between
> the following:
>
> call system ("")
> i=system("")
>
> The compilers warned about this at compile time.
There could be 2 reasons for that. Either there was a prototype
available and the compilers checked against that, or system() was
implemented *inside* the compiler as a language feature, hopefully
calling the system's system() whether or not the internal
implementation was subroutine or function. In the latter case, it
would have nothing to do with libpgc.so.
Let's say that the Fortran system() is defined in libpgc.so. You must
have information, at least in terms of documentation, on whether the
library implements it as subroutine or a function. You write a call to
system() the "right" way, and the compiler is not in the picture.
> I worry that such a change, if left to the linker to check, will get
> unnoticed. I know that when I get an error from the linker, when
> doing the static linking, it announces missing function_name_, and
> not function_name_(int *, int *) like it would in c++.
It is a function of what the linker reports, what options you switch
on, and how the language (implementation) works, e.g., whether you can
call foo(a,b) as foo(a) (with b initialized to a default or
garbage). In the latter case the compiler will do the right thing,
from its point of view, and it is not a question of library
compatibility. In the former case an error may go unnoticed if the
linker is buggy or permissive by design or by usage, but you cannot
fix that by checking the version of the compiler.
I think you are trying to assign to the compiler functions it does not
perform, e.g., checking whether a
Re: dial by ordinary user
On Fri, Apr 07, 2006 at 05:10:43PM +0300, Lior Kaplan wrote: > On Debian, you can add the user to dialout group. Does this allow the user to generate a new network interface? Not to mention that this may be over-permissive. I ended up using sudo for two simple scripts: The "dial" wrapper runs basically 'poff; ponn' and the "discon" wrapper runs basically poff . Then I wrote two scripts, 'dial' and 'discon' that run 'sudo /usr/local/sbin/dial_script' (or 'disconnect_script', respectively) BTW: I made a simple network interface with the ppp method under /etc/network/interfaces and made it start automatically. Works well. In my case this is pppecidial. But should work equaly well for pppoe. -- Tzafrir = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
dial by ordinary user
Hi Lior, Thanks for the answer. It's not that: Quoting: ->On Debian, you can add the user to dialout group. 1-According to Javier Ferna'ndez-Sanguino Pen~a <[EMAIL PROTECTED] org> : Securing Debian Manual ... "* dialout: Full and direct access to serial ports. Members of this group can reconfigure the modem, dial anywhere, etc. * dip: The group's name stands for "Dial-up IP", and membership in dip allows you to use tools like `ppp', `dip', `wvdial', etc. to dial up a connection. The users in this group cannot configure the modem, but may run the programs that make use of it. I have configured pppoe as root. I only tried to use it as mavram. So dip should have been good enough. 2-Got the same error messages after adding the group dialout. ->man pon gave me: Note: the plog script can only be used by root or another system administrator in group "adm", due to security reasons. I forgot to mention that mavram belongs to group adm as well. Cheers, Avraham = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Shared Object, ID yourself
On Fri, 7 Apr 2006, Oleg Goldshmidt wrote:
> Date: Fri, 07 Apr 2006 21:13:03 +0300
> From: Oleg Goldshmidt <[EMAIL PROTECTED]>
> Reply-To: linux-il@linux.org.il
> To: Orna Agmon <[EMAIL PROTECTED]>
> Cc: linux-il@linux.org.il
> Subject: Re: Shared Object, ID yourself
>
> Orna Agmon <[EMAIL PROTECTED]> writes:
>
> > The compiler comes with a sort of "portability package". Shared
> > objects, which must be on the machine where the program (compiled
> > using PG compilers) is run.
>
> OK, the way I parse this is as follows: your program is linked with
> this library, the compiler (also a program, of course) is NOT linked
> with this library. What follows makes any sense only if this
> understanding is correct. If the compiler uses the library *during*
> compilation, then you have an issue, and this posting is irrelevant.
>
> > I do not expect the interface between my program and the shared
> > object to stay the same over major versions of the compiler
>
> Why not? The interface is between your program and the library, why is
> the compiler involved?
>
> Let's analyze the situation. The "code" I will be discussing is the
> code of libpgc.so, *not* the code of the application that you are
> developing. This is going to be a bit long-winded, but bear with me.
>
> Disclaimer: there almost certainly are people on this list who know
> the internals of the toolchain so well that they will be able to point
> out that GNU ld / Linux / Solaris / AIX / whatever works not precisely
> as I describe, etc. What follows is "broad strokes", describing the
> general principles only.
>
> Now, down to business. The code originally contains symbols, such as
> "int count", "goto label", etc. (C, Fortran - spare the audience the
> details). Ultimately, "goto label" has to be translated to "jmp
> 12345", whatever, i.e., in the end the CPU must operate on the
> *absolute* (virtual!) memory address.
>
> The compiler (not yours in this case, the one the shared library was
> compiled with, though yours does the same) does *not* (unless it is
> MS-DOS or something equally obsolete) generate absolute
> addresses. Instead, it generates "relocatable" addresses, something
> like "32 bytes from the beginning of this module". The notion of
> "module" has to do with "dynamic loading": modern systems recognize
> that not all the code is needed at the same time, and some code may
> never be needed at all. So chunks of the program are loaded as
> needed. Your "hello, world" program will load printf, but not
> necessarily strncmp, even though they are in the same library. Your
> own error handling code will hopefully not be needed during the normal
> operation of you program, etc.
>
> So when do we get the absolute addresses? Sometimes at load time -
> once a module is loaded into memory, its "beginning" is associated
> with an absolute address, and thus all the relocatable addresses
> belonging to this module can be converted to absolute ones. Even this
> is rare on modern systems, though: this would mean that to move the
> program around one would have to reload. So modern systems usually
> bind addresses at runtime.
>
> This is not all. The above is not enough for code *shared* between
> several processes. The reason should be transparent: shared code
> cannot depend on its location in the virtual address space of a
> process, as we cannot guarantee that this location will be the same
> for every process sharing the code. This is why the compiler must
> generate "position-independent code" (this is where gcc's -fPIC option
> comes from). Normally, this works through "indirect addressing": there
> is a per-process linkage table that maps modules to absolute
> addresses. Filling this table is a function of the loader, which is
> done - again - at runtime.
>
> What's the point of this discourse? The point is, the procedure does
> not depend on what the compiler that you use to compile *your* code
> does. Your code wants to access an object from the shared library. The
> compiler does not really do much besides arranging for a jump to the
> linkage table. It is the linker that is responsible for finding the
> object in the library and arrange for the corresponding record in the
> table. It is the loader's job to create and fill out the linkage table
> at runtime. In fact, instead of the actual object the absolute address
> specified will point to a "stub" function that will transfer the
> control to the OS. It is the OS's job to figure out whether the
> accessed library object is in fact in memory, and if not, instruct the
> loader to load it, and to *modify* the stub to jump directly to the
> object on subsequent accesses ("dynamic linking").
>
> Note who does the work: linker, loader, OS. There is no requirement
> that the shared library and your code be compiled with the same
> compiler. The important work is done by the loader and linker
> anyway. Of course, if the library API changes, then it must be
> reflected in your code, but that's unrel
