This is interesting. I've been planning to add play-by-mail support to my mooix moo, but have held off because I didn't want to tackle doing it securely. But if I can just use grunt and it turns out to be secure.. that'd be sweet. I hope that grunt lets you just compose commands with a standard mailer, without having to run some command on your system to set up the random block John mentions. For my (very specific) purposes, it would be nice if it could be used without gpg, from any system that can send and receive mail. Brian May wrote: > No, I think it is an inherent problem with using E-Mail for such things. > > As long as E-Mail is used, the possibility exists that the E-Mail will > get delayed. > > If the E-Mail gets delayed it is not possible to cancel it, it has > already been sent. > > An E-Mail could go missing due to bad mail configuration, could get > delayed due to a link going down, or deliberately (for example). This could me especially amusing if the first, delayed email was: cd /tmp And the second was: rm -rf * (Dumb contrived example, but you get the idea.) You could possibly do stuff with seqence numbers though to prevent this. If every command you sent was a reply to a message from the grunt server (the response to the last command), the server could generate a new number each time. Something like this: From: me Subject: hi, I want a grunt session From: grunt server Subject: your session started Be sure to reply to this message to include this data -- Session-id: 240943 Sequence-number: 1 From: me Subject: my first command cd /tmp > Be sure to reply to this message to include this data -- > Session-id: 240943 > Sequence-number: 1 From: grunt server Subject: re: my first command > cd /tmp pwd: /tmp Be sure to reply to this message to include this data -- Session-id: 240943 Sequence-number: 2 From: me Subject: my second command rm -rf * > Session-id: 240943 > Sequence-number: 2 If the cd command is intercepted or delayed, then I'll notice that the server is not responding back. I could then try to resend it, superceding my old command (which the server would discard if it got it, since its sequence number for this session would increase). Unless I'm terminally stupid, I cannot send the second, dependant rm command until the first command gets run. I'd have to forge the sequence number (2). The server could even protect from this by using randomly increasing sequence numbers, at-la-tcp. I could also try to cancel the whole session, with another mail. If the mail got through, that would prevent the interceptor from feeding it to the server at a later date. However, they could just intercept the cancel mail too. That's about the time I think I'd reach for out of band communication. -- see shy jo
Attachment:
pgpm2NASgeQQz.pgp
Description: PGP signature