Older blog entries for lkcl (starting at number 158)

busy. houses. car. no money. passing zero point in two weeks. couple of prospects. might _just_ be enough. still irritated with open source advocates given that there's no money around to even make sure shit happens. i have a hell of a lot to do, and i need about ten to twenty million to make it happen. then i can get on with it without taking shit from anybody. the ridiculous thing is that what i do will save people and businesses hundreds of millions of dollars in license fees, world-wide.

classis quotes from my teenage sister:

i was so ill i couldn't eat the other two chocolate cakes...

teehee. well, i am hoping to get either a positive response or _no_ response from mr william gates, and then EU directives cut in. interesting to note that those law professors declared the DMCA unconstitutional...

well, into the freedce client-side state machine i added the 3-way auth, and off it went, wha-hey. took me a while to notice that the code was fine, i was just using the wrong password... *muuur* :)

progress being rapidly made, have a netlogon.idl file i recreated, and lsarpc.idl, winreg.idl and a couple of others courtesy of matty. the neat thing about dce/rpc is that when you have the IDL file you *automatically* get a header-file and client-side API immediately.

if you already have [someone else's] server to play with, e.g. NT, you can use it IMMEDIATELY.

so, for example, we have a winreg.idl file therefore we AUTOMATICALLY have a complete Windows Registry API - for Unix.

i'm trying to get the wine development team's attention with this one, maybe i should try more eye-catching subject lines... :)

oh, man. the freedce (OSF 1.1 dce/rpc reference implementation) is _deep_.

i just started phase 1 of the NTLMSSP (NT security) server-side implementation, as mentioned earlier, and am now on client-side.

dce/rpc auth negotiation involves potentially multiple packet exchanges, even handling splitting a large authentication request and a large authentication response into multiple PDUs (protocol data units, equivalent to TCP (dis)assembly from UDP).

however, some authentication mechanisms - most notably but not limited to NTLMSSP - require a 3-way handshake. so you get BindRequest, BindAcknowledge, Auth3 and you're done, and then proceed to FnRequest, FnResponse exchanges to do in/out parameters.

so that's send, receive, send, [send, receive]*.

the freedce code implements its packet exchanges, both client and server-side, as a bloody _state_ machine. which explains why there are so many bits and pieces in the various headers because dce/rpc handles _per thread_ security if you need it, etc. etc.

basically, ten threads are allocated and because it's a state machine, a server can pretend to be able to cope with more simultaneous requests than it actually has threads. sort-of :)

very, very neat.

anyway, to cut a long story short, the server-side state machine copes perfectly well with 3-way authentication handshaking and, whilst there are comments in the code regarding client-side 3-way auth, it's not bloody well _in_ there.

argh! :) :)

well, the site goes well: behind the scenes is some quiet work going on. osexchange moved to dcerpc.net. NTLMSSP as an auth/sign/seal module, which is like the first real step in getting NT interoperability, is slowly progressing well. i have a successful server-side authentication and sign/seal decryption working, as long as the password is "test".

the problem here is the dependencies. NT authentication requires NT services and an NT-compatible API. without the NTLMSSP in place, i can't test the authentication because i don't have an API to use to actually validate the user!

_fortunately_ i can use rpcclient which i developed over four years as a test-tool. this i am really pleased about, and am learning a lot more - having access to freedce source - about dce/rpc than i was by just bouncing packets off of NT.

what i am really pleased about is to have a third dce/rpc-compatible "thing" in the picture against which to test interoperability.

_un_fortunately, this finds that there are bugs in the entire TNG/samba rpcclient / samrd NDR marshalling / unmarshalling libraries. well, of _course_ they are. it looks like microsoft was being incredibly lazy and just getting "wire-compatibility" [just like me *grin* except i have an excuse: for copyright and interoperability reasons, i couldn't look at any specifications]. so, if it "worked" when we bounced packets off of NT services, well, then, it worked, and that's the end of it.

but now we have _real_ functionality, by the people who actually _wrote_ dce/rpc, and of course, rpcclient fails in specific instances against freedce because we didn't know any better.

gonna be interesting.

and a lot of work, for which i am still not being paid. which is irritating, to say the least, given that this effort provides the entire open source community with an extremely valuable tool which, if nothing else, finally allows them to catch up with microsoft's last ten [physical, not man] years of development in key, strategic areas.

dcerpc.net

number of development man-hours for TNG / dcerpc.net CRITICAL PATH components comes to over 600 man-hours.

you would do well to look up the reasoning being SURS - SID to UID/GID Resolution System. it sounds like exactly the same sort of thing is needed. draft-lkcl-sidtouidmap-00.txt what is _really_ needed is for Unix systems to adopt GUIDs or SIDs for world-wide user and group identification, rather than locally-applicable uint32s or uint16s that stuff everything up rather badly when it comes to very large networks.

NT is actually far better positioned than unix, due to its use of the VMS security model, to provide worldwide security.

muhahahah no more mr microsoft. at the gluug last week, someone said "ere, neone want dis suse 7.1?" to which i replied "me! me!" and given that noone claimed it, it's now mine, all mine. muhahahahh.

heather's work computer has the mtx virus. heather's _other_ work computer now has suse 7.1 :) heather's work computer with fuckwit microsoft and a very special infection is now sitting on the other side of the room. it gave me a peculiar thrill to be able to remove the network settings from it [peculiar, because _i_ am].

it was just... particularly satisfying to have the dialup / internet connection replaced by kmail and staroffice, and other than getting the username and password the wrong way round in wvdial, it works absolutely perfectly.

the only thing that's really irritating is that i am surrounded by no less than _three_ dot-matrix printers, one special tiny labelling inkjet printer and a lexmark bubblejet printer. begs the question, really.

there is currently a quite irritating little competition going on between two of the dot-matrix printers as to which can make the most noise...

now, really, all i have to do is to test out the special printing program under Wine and then it may be possible to reinstall the damaged [virus] computer with linux too...

i was extremely concerned by the "fear in the geek community" article when it came out. i am ever so relieved that there have been so many responses that recommend alternatives to killing.

[but, funny that no-one else said 'yes, the idea of going to give blood is good'].

oh my good. bush wants war on terrorism. i bet they're all lining up with glee and itching for a fight.

bush has just INVITED terrorists - including those who weren't currently active - to step forward, cap-in-hand to sponsors across the world, into the ring, for a round against the united states.

fuck me, what utter stupidity.