mirror of
https://github.com/opsxcq/mirror-textfiles.com.git
synced 2025-08-16 23:54:23 +02:00
166 lines
7.8 KiB
Plaintext
166 lines
7.8 KiB
Plaintext
From smcg@cs.hw.ac.uk Mon Jul 17 12:49:31 1989
|
||
From: smcg@cs.hw.ac.uk (Stephen McGowan)
|
||
Subject: Re: Beer - it's no joke!
|
||
|
||
|
||
|
||
--------------------------------------
|
||
BUGS. DON'T LIVE IN IGNORANCE.
|
||
--------------------------------------
|
||
|
||
|
||
-------------------------------------------------------------------------------
|
||
1. Why Are You Being Sent This Message?
|
||
-------------------------------------------------------------------------------
|
||
|
||
This message is being sent to every software house in the country. It is about
|
||
BUGS. And everyone needs to know the facts. It explains what BUGS are, how they
|
||
spread, how serious the threat may be, and how they can be avoided.
|
||
Because it has to deal with matters of software and hardware, you may find
|
||
some of the information disturbing. But please make sure that everyone who
|
||
needs this advice reads this message. The more people who know about BUGS the
|
||
less likely they are to spread.
|
||
|
||
So, if you employ programmers, think carefully about what they need to know.
|
||
Whether or not you approve, many programmers do write programs, and some may
|
||
experiment with assembler.
|
||
|
||
Even if you think your programmer's don't act in this way, they will still need
|
||
advice because they may have friends who encourage them to.
|
||
|
||
|
||
-------------------------------------------------------------------------------
|
||
2. Why Should You Be Concerned About BUGS?
|
||
-------------------------------------------------------------------------------
|
||
|
||
Any computer user can suffer from BUGS, depending on their behaviour. It is
|
||
not just a hacker's problem. There is no cure and they can cause crashes. By
|
||
the time you have read this, probably 3000 computers will have crashed in this
|
||
country. It is believed that a further 400,000 carry BUGS. This number is
|
||
rising and will continue to rise unless we all take precautions.
|
||
|
||
-------------------------------------------------------------------------------
|
||
3. What Are BUGS?
|
||
-------------------------------------------------------------------------------
|
||
|
||
BUGS are caused by logical errors. These can attack a program's validation
|
||
routines which normally help fight off bad input and corruption. And if this
|
||
happens then programs can develop BUGS. They become unreliable and crash from
|
||
errors that cannot be detected.
|
||
|
||
|
||
-------------------------------------------------------------------------------
|
||
4. How Do Programs Become Infected?
|
||
-------------------------------------------------------------------------------
|
||
|
||
Because errors can be present in specifications and designs, this means that
|
||
for most programmers the only danger comes through using a faulty design. This
|
||
applies to both top-down and bottom-up design. (It is believed that other forms
|
||
of design are also risky, such as SSADM, particularly if specifications are
|
||
taken at face value.)
|
||
|
||
So the errors can be passed from design to design, design to program, and back
|
||
again from program to design. For those who use assembler there is an added
|
||
risk from sharing software interrupts or device printers on a time-sharing
|
||
basis. Furthermore, sub-tasks spawned from infected programs have a high risk
|
||
of inheriting BUGS.
|
||
|
||
-------------------------------------------------------------------------------
|
||
5. How Can You Protect Yourself From BUGS?
|
||
-------------------------------------------------------------------------------
|
||
|
||
(a) Most programs which have errors don't even show it. They may look and
|
||
behave completely normally. So you cannot tell which ones are infected and
|
||
which ones are not. To protect yourself, follow these simple guidelines;
|
||
|
||
(i) The more programs you write, particularly assembler programs, the more
|
||
chance you have of encountering one which is infected. It is safest to stick
|
||
to one program.
|
||
|
||
FEWER PROGRAMS, LESS RISK
|
||
|
||
(ii) Unless you are sure of a program, always use a debugger. This will
|
||
reduce the risk of encountering BUGS.
|
||
|
||
USE DEBUGGERS FOR SAFER PROGRAMMING.
|
||
|
||
(iii) It is always best to use a source-level debugger. Low-level debuggers
|
||
can reduce this protection. Ask your team-leader for advice. Anyone who uses
|
||
assembler programs should not use software interrupts. If you do, never share
|
||
interrupts (or device handlers, floppies, etc) as you could be introducing
|
||
BUGS directly into your program.
|
||
|
||
DON'T USE SOFTWARE INTERRUPTS. NEVER SHARE.
|
||
|
||
|
||
-------------------------------------------------------------------------------
|
||
6. What Should You Do If You Think Your Program Has Been Infected?
|
||
-------------------------------------------------------------------------------
|
||
|
||
If you think your program has been infected, go to your course leader for
|
||
advice about having a test. Or go directly to your personal tutor for private
|
||
and confidential advice and a test if you wish. If your program does have
|
||
errors, they'll let you know and give you help and support.
|
||
|
||
|
||
-------------------------------------------------------------------------------
|
||
7. What About The Resident Software?
|
||
-------------------------------------------------------------------------------
|
||
|
||
It is not safe to use comms packages, Armstrad applications or on-line
|
||
dictionaries unless you know they are bug free and have been rigorously
|
||
tested. Nor is it safe to share a routine or include a file in a program
|
||
which has been infected.
|
||
|
||
-------------------------------------------------------------------------------
|
||
8. What Can't You Get BUGS From?
|
||
-------------------------------------------------------------------------------
|
||
|
||
The government's clear advice for the software industry is that you CANNOT
|
||
get BUGS from normal use of an infected program. Neither can you get them
|
||
>from reading listings. Nor is there any record of a program becoming infected
|
||
through sharing comments. There is no danger in sharing floppies or micro-
|
||
drives. Nor can anyone become infected through using network drives or line
|
||
printers.
|
||
|
||
When integrating software, standard precautions should be taken to protect
|
||
programmers, users and applications. Exporting routines are safe: all the
|
||
declarations are used only once. All routines used for library builds should
|
||
be thoroughly checked.
|
||
|
||
-------------------------------------------------------------------------------
|
||
9. How Safe Is It In Other Countries?
|
||
-------------------------------------------------------------------------------
|
||
|
||
BUGS exist throughout the world and throughout the computer industry. In
|
||
certain companies a large number of programs are believed to have BUGS. So it
|
||
is even more essential to follow the advice given in this message, particularly
|
||
if you should visit another company. Otherwise, if you do some work on an
|
||
unfamiliar program, you may inadvertantly affect your regular work when you
|
||
return.
|
||
|
||
Furthermore, in some companies, public routines are not checked for BUGS. In
|
||
those places where errors are widespread you should not, if you can possibly
|
||
avoid it, use routines from a contract programmer.
|
||
|
||
In certain start-up companies, routines may not be properly debugged. If you
|
||
can, avoid using interrupt repairs or patches. If you are in any doubt about
|
||
these points then discuss them with your course leader.
|
||
|
||
|
||
-------------------------------------------------------------------------------
|
||
10. Do You Need More Information?
|
||
-------------------------------------------------------------------------------
|
||
|
||
The true picture about BUGS is that, at the moment, relatively few programs
|
||
are infected with proper full-blown BUGS. Those most at risk are assembler
|
||
programs which have common code with other assembler programs, programs
|
||
which share software interrupts, and users of these programs.
|
||
|
||
But BUGS is spreading. And as it does, so the risk of sharing an infected
|
||
routine also increases.
|
||
|
||
Ultimately, defence against BUGS depends on us all taking responsibility for
|
||
our own logical and programming actions.
|
||
|
||
|