Security implementation for INTERNET
Sillyman
topic again. What about INVESTIGATE? This command is necessary for
some semblance of security. Syntax would be something like:
INVESTIGATE MISSING (Variable)
This would ask the theft server who stole (Variable) and keep the
results in a list of open cases.
Other commands related to this include:
FILE CASE (Expression) IN (Variable)
This statement stores the process ID provided by the server on the
(Expression) case into (Variable) and closes the case, deleting it
from the list.
ARREST THE PERPETRATOR OF CASE (Expression)
This statement executes the commands defined by the most recent
MINIMUM SENTENCE, and allows for a later SENTENCE command. It will
then become an error to do any action on the case except FILING and
SENTENCING.
REOPEN CASE FROM FILE (Variable)
This statement makes a new open case with the value in the variable
assumed to be the process id of the accused, and clears the variable.
It is not an error to reopen a case that is not a case.
CLEAR ACCUSED IN CASE (Expression) OF ALL CHARGES
This closes a case without taking any further action.
MINIMUM SENTENCE SHALL HENCEFORTH BE READ FROM (Expression)
If this statement is encountered followed by an ARREST statement, the
statements at line (Expression) shall be executed, and the ARREST
statement shall be returned to when the END SENTENCING command is
encountered. It is an error to GIVE UP before you END the SENTENCING.
SENTENCE (Expression1) TO (Expression2) AND DEFINE PARTY (Variable) TO
BE THE PERPETRATOR
This will STASH (Variable), execute the statements at line
(Expression2), with (Variable) set to the perpetrator of the case
(Expression1)'s session id, and return to the SENTENCE statement,
RETRIEVE (Variable), and close the case when the END SENTENCING
command is encountered. It is an error to SENTENCE a process id that
has not yet been ARRESTED, or to GIVE UP before you END the
SENTENCING.
SENTENCE (Expression1) TO (Expression2)
Same as the above statement, but without anything relating to
(Variable).
Errors:
COURT IS STILL IN SESSION: Results from GIVING UP while SENTENCING is
not ENDED.
THE ACCUSED IS NOT GUILTY: Results from SENTENCING a process id that
has not yet been ARRESTED.
THE ACCUSED HAS ALREADY BEEN FOUND GUILTY: Results from taking an
action other than FILING or SENTENCING on a case that has been
ARRESTED.
Right, tell me if I missed anything. I hope this is weird enough for
INTERCAL.
Claudio Calvelli
> I got the strangest idea while reading the "INTERCAL for the FUTURE"
> topic again. What about INVESTIGATE? This command is necessary for
> some semblance of security. Syntax would be something like:
This may introduce an unwanted side-effect. Let me explain. At present,
to implement a two ways communication between two programs, one must
find the way to exchange process IDs (and IPs if appropriate) before
you start. Only after you exchanged this information the two processes
can take turns using STEAL/SMUGGLE.
At present, it is possible to open a temporary file twice, storing
the two filehandle in different variables. Then wait for some other
process to STEAL one of them and store all the required information
in the file; meanwhile, use the second filehandle to check for changes.
As soon as the information has been passed this way, the protocol can
continue using STEAL/SMUGGLE. It can also continue using the temporary
file for communication, but this is morally wrong, although at present
it does not produce an error. Maybe there should be a limit in the number
of operations one makes on a shared file.
(It is possible to open the file just once, IGNORE it, and wait for
somebody else to SMUGGLE it away. This works because you can obviously
WRITE IN from an IGNOREd file, although you are not supposed to modify
it - which you can at present, but this is undocumented, a bug, and I
never told you you can - but don't let me stop doing it anyway - however,
this also introduces synchronisation problems as the file can be
SMUGGLEd by several processes, while it can only be stolen by one -
anyway, end of aside).
The introduction of INVESTIGATE would allow to write a two-way
communication between processes by waiting for a variable to be
stolen, at which point INVESTIGATE would provide all the information
necessary to do the next bit, STEAL back from them, repeat as necessary.
I am not sure this is such a good idea.
On the other hand I have to admit that I like the idea, and I don't
care if I am contradicting myself.
I STASHed the article away in the CLC-INTERCAL sources for further study.
Claudio "intercal whirlpool intercal spot dyn-o-saur spot com" Calvelli