|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
BUGS: Don't live in ignorance
--------------------------------------
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.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
