free software

[Max V. Zinal]

Dear Dr. Ernst Molitor,

> Werner Koch will possibly comment on his view of "regular code"; my view
> is that "regular code" is code that follows standards. The kind of
> "portable software" you are alluding to is very hard to write and
> maintain. Please note that there is but one way to be sure a give
> sources can be compiled flawlessly in a a certain environment and with
> compiler brand: Checking it out, which means you need access to both the
> environment and the compiler. For proprietary systems, this in turn
> means you have to cough up enough bucks to buy them. I'd rather watch
> programmers working on free software (in the GNU sense) to spend their
> dollars (or rubels, or whatever currency they may use) in a more
> reasonable way :-)

Well, I'm not talking about "being sure" in compilation success for any 
specific environment. I do think that "regular code" in any sence should 
follow standards - although even POSIX is a "big country with many 
cities, towns and villages" :). But I'm pretty shure that OS-specific 
facility should be separated from the "regular code" in a better way 
than many of today's GNU projects demonstrate. This can save a lot of 
time, although requires some care in design. IMHO this is good for 
portable, widely-used software.

> With viruses that infest Windows machines and select files by random
> from their hard disks to send them via SMTP to addresses selected from
> address books found on the boxes, I can hardly imagine a sound use of
> GnuPG in this environment. Can you? 

Too much panic is about that problem. Linux is not an angel in that 
sence, nor Solaris, Tru64 UNIX, AIX or IRIX. You are almost safe if you 
use an rarely-used, corporative OS (OpenVMS may be a good example). I 
can see two sources of "anti-Windoze movement" :) :
   - Microsoft's policies, which are often not friendly for their users;
   - unavailability of source code for OS components.
These to statements increase the security risk for the user, but it 
cannot be measured anyway. According to my experience, this risk can be 
minimized to a very small value (for common tasks, not for nuclear 
technologies or medical software :)) by making a carefully-tuned setup.

> The "OS-abstraction-layer" you envision is an impossible thing to write
> for programs that strive to work in a  safe and secure manner. You wan't
> be able to provide an "abstraction layer" that will assure your program
> to avoid swappable RAM for certain memory blocks via an "abstraction

Needs to be proven. Here is a small objection against your words:

Any OS API is a kind of abstraction layer on the top of specific 
characteristics of the hardware, especially for portable systems.
Do you mean that defining OS API is impossible? :)

> layer", if for no other reason than that the instructions available to
> this end on some systems are lacking on others (and even worse, some
> have instructions that promise such a behaviour, yet fail to stand up to
> what they promise). 

If you are talking about Win32 VirtualLock(), then you are not right. It 
*really* works as defined in the OS documentation, although this 
fragment of docs requires very careful reading. VirtualLock does not 
lock anything - it just ensures that access to the specified memory 
pages *initiated by the calling process* will not lead to a page fault.

> In this (admittedly sad!) situation, I'd suggest to stay with
> environments that can possibly offer a reasonable amount of security,
> and to avoid wasting valuable programmer's time on providing "portable
> software" for systems that have weaknesses that can't be addressed with
> a program like GnuPG. After all, the chain (of security) can't be
> stronger than its weakest part (german saying...). 

We are living in a non-ideal world. After all, there too much opinions 
about "the correct behaviour", especially in the software field. A good 
system administrator will never think of his system as "100% safe". 
After all - trust but check (russian saying:).

Best regards,
   Max V. Zinal