RE: [MiNT] Security again

[Jo-Even.Skarstein@gjensidige.no]

> -----Original Message-----
> From: Konrad M. Kokoszkiewicz [mailto:draco@obta.uw.edu.pl]
> Sent: Wednesday, November 17, 1999 11:28 PM
> To: Jo Even Skarstein
> Cc: mint
> Subject: Re: [MiNT] Security again
> 
> is only the price of the solution). Now we make the Cookie 
> Jar mode off
> :-) in this discuss (and I promise I'll come up some day with 
> something
> else to fix that thing :-)).

I'd say that real solution would be to protect the kernel itself, but IIRC
this is not trivial :-( I'd really like to see some clever mind coming up
with a solution for this.

> Well, I can perfectly and happily live without BubbleGEM (I 

Me too, it's a nice concept but heavily overused (by me as well, I admit
it). Those nasty bubbles pops up everywhere. But most people like it, it
looks good on screenshots ;-)

> kicked it out
> awhile ago because it seemed it causes some problems with 
> GEM, and really,
> the problems have gone away after I put the BGEM to the trahscan),

I know, the implementation is not as good as it could have been. I wrote a
windowed replacement myself, but it turned out even worse than the original
:-)

> Nevertheless, I think there should be an alternative way to 
> communicate
> with such a program (DHST server), other way than the cookie 

Definitely, but who will use it? DHST-servers only puts their APID in the
cookie, a much cleaner way to announce it's presence would simply be to use
menu_register(-1, "DHSTnnnn"), where "nnnn" is a unique string (e.g. "TSKB"
or "_SMU").

> jar, so what
> about talking to the author of the DHST protocol about an expansion?

I don't think Thomas Much develops TOS-software anymore.

> Well... in such a case solution is easy ------> trashcan. And 

Sure. But this is not an option for everybody.

> there is a need for a decent programming doc for MiNT, to avoid a
> situation, that some programming technique is not valid and 
> has a cleaner
> replacement, but software developers answer: "But Atari documentation
> dated 14. July 1415 AD says, that..."

This is not really a MiNT-issue, it affects MagiC and Geneva as well. The
problem is that otherwise brilliant coders doesn't think at all when they
use the cookie-jar (IIRC Jinnee and Keywatch is written by the same person),
for some strange reason they don't understand the consequences their
implementation has on stability. In fact, it's a much more serious problem
for MagiC-users than for us, because...

a) ...MagiC-users tends to use more of these flashy things like Stic and
BubbleGEM.
b) ...MagiC's memory-protection can not catch things like e.g. Keywatch
calling user-installed functions in crashed/killed processes. Hmm, bad
example, MiNT can't either... But atleast MiNT doesn't commit suicide if
Stic crashes with running clients.

I think the solution must be to make these developers aware of what they're
doing. For some strange reason many of them think that the real problem is
MiNT's memory-protection and *not* their implementation!

Jo Even Skarstein