23 May 2003 grey   » (Journeyer)

Despite my best intentions, this might temporarily be a place for me to just get down some ideas short version of why is due to another imminent move; moving makes it hard to get one's network set up. Yet another reason for why I really need to do a colo somewhere decent. Of course that requires time & money to get organized with - and I will have neither until after the move. That said.

I had another brainstorm on scp&sftp resume support this morning. One pain in the ass problem with ftpd's & resume is that you need to give people overwrite permissions - but if this is say, an anonymous upload dropsite, you don't want some dick overwriting all your files. Since SCP/SFTP have a key exchange at the beginning though - and since everyone will have a different public key, then even though account-wise they'll all be anonymous, you _can_ actually distinguish between people who should be able to "overwrite" (really, resume) their files, and people who are just trying to be malicious and fuck with other people's stuff. So, if there's a match on the public key received, you say - "oh yeah, please finish uploading that file that got screwed," and if it's not you say - "sorry, you're not the droid we're looking for, try resuming your own files." I realize that this is a bit in the face of p2p crap - but I'm trying to think of security first; if this idea ever gets further than the idea stage, that would merely be default behaviour - a site admin could always override it allowing people to overwrite anyone's files, or you should be able to have granularity to do it file-by-file. One thing (might already be there for scp) is to do like a sha-1 of a file before xfer, and then have the remote end sha-1 it after completion to improve the likelihood of file integrity too. That's an older idea, and could maybe be done in other ways.

Some hangups - I spoke briefly with Niels the other day about resume support - and he said that theo had some gripe about adding it (some BS about malicious jazz - but hey, the ftp stuff in OpenBSD support resume, why should scp be so different in that functionality I wonder? Need to hear more details). Niels was going to bring it up again with markus, but I get the feeling that it might not happen. Or, if it does, not in an official OpenSSH branch (for now at least). Still really disheartening to see effects of the fallout even now, even though I'm just a user.

Meanwhile, this is really just a wishlist. I'm getting back into programming, but it's been ... like 9-10 years. My biggest frustration right now is that I have a -lot- of ideas, but no skills to actually know how to implement them. Still, I have to say that this year's CanSecWest & meeting jose & jsyn in person in particular was extremely inspirational. (Anecdotes at a later date perhaps).

--------------------------------------

Some other things I want to see out of SCP/SFTP server in the future:

- No need for a real shell [see earlier discussion]; ideally even have something like a chroot & fake 'accounts' akin to ftp4all - I don't want the users to have real access to the system at all, that way too you could have fs granularity like ftp4all that's beyond what the system sees, because it's handled more by .

- Resume support [discussed in greater detail above].

- Maybe intelligently set the dumpsite to a noexec partition, dunno if it would really help much; but something to peak into. Could also systrace everything to limit file creations strictly to a partition.

- Maybe _maybe_ put rate limiting support into the application [I know, this can be done in altq etc., but especially if this is aimed more at file xfers - you don't want it to interfere with your standard ssh or tunnelling priorities in all likelihood].

-------------------------------------------------------

Enough spew for now, I really need to get this stuff off advogato at a personal colo soonish.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!