cooler heads...
Mar. 5th, 2005 02:18 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
acroyearfrom ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
subbes by way of greendalek: Fight Misinformation (about frienditto)
hint: its bad, but so are a million other ways to do it. if you can't trust someone to not publish something locked, you can't trust them, regardless of the hows they would do it.
hint2: i don't care what it is -- don't give anything your password.
hint3 for geeks only: if there's an open-source archival tool that can be inspected to make sure its doing nothing more with your password than simulating a log in, grabbing your own posts (and comments) and archiving them on your own machine with no hint of putting them in any publically viewable space, then ok, you can use it. Its a utility, not a service, and as such you're in control...but only after you've inspected the source to be sure that's all its doing.
hint4: even with #3 above, i don't think its cool to use said thing to archive other people's stuff automatically. if there's something you want to remember, add it as a memory. that's what LJ put that memory system up there for. if they take it down, that's their perogative. respect it.
subbes by way of greendalek: Fight Misinformation (about frienditto)hint: its bad, but so are a million other ways to do it. if you can't trust someone to not publish something locked, you can't trust them, regardless of the hows they would do it.
hint2: i don't care what it is -- don't give anything your password.
hint3 for geeks only: if there's an open-source archival tool that can be inspected to make sure its doing nothing more with your password than simulating a log in, grabbing your own posts (and comments) and archiving them on your own machine with no hint of putting them in any publically viewable space, then ok, you can use it. Its a utility, not a service, and as such you're in control...but only after you've inspected the source to be sure that's all its doing.
hint4: even with #3 above, i don't think its cool to use said thing to archive other people's stuff automatically. if there's something you want to remember, add it as a memory. that's what LJ put that memory system up there for. if they take it down, that's their perogative. respect it.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-03-05 11:53 pm (UTC)only if you use someone else's binary...
Date: 2005-03-06 12:52 am (UTC)also depends on what is "hacked". a tool to login to LJ for you, do the archiving, and terminate doesn't stay behind with open sockets to be picked off by 'bots and spiders.
Re: only if you use someone else's binary...
Date: 2005-03-06 01:27 am (UTC)The above poster says ...but only after you've inspected the source to be sure that's all its doing. this insinuates that open source apps that allow you to inspect their code are therefor impenatrable. That is incorrect.
There are SEVERAL widely used open source applications with very extensive development teams and lengthy code audit procedures in places. They've all been "hacked" or found to have remote vulnerabilities. I gave a couple of the most famous examples. Most of the time these things ARE compiled natively.
Re: only if you use someone else's binary...
Date: 2005-03-06 03:16 am (UTC)apples and oranges.
1) the kind of code i'm talking about is not a resident server, where receiving connections by opening ports (usually where the "buffer overflow" stuff comes from) doesn't happen. what i'm talking about is a tool that opens a connection to LJ (normal HTTP), grabs the stuff it wants, and closes. nothing for anybody else to attack.
every app you mentioned is a server. also, most of them are *old* code where buffer overflows were more common (because of the use of the "gets()" call which is unbuffered and easily leaks into other memory spaces that way). they're also heavily dependent on the underlying C library (which is likely buggy in ways undiscovered 'til exploited).
they're also all unbelievably complex for what they do.
on the other hand, the exploits get fixed *fast*, don't they?
2) of course it has to be compiled "natively". my point is, are you the one doing it? If i examine source code to see that it fits what i want it to do and has no open holes, then I compile that code, and i run that binary, there is no way in hell anybody else can have gotten in there to add a trojan.
(the only exception being the infamous cc + login.c, where one of the unix inventors supposedly put in a back door that cc placed into the binary code when it compiled login.c, then new code so that it recognized when it compiled cc.c and put in the code to put in said back door, then wiped it from cc.c once he had the bootstrap. years later, the back door was still there because everybody was using a cc bootstrapped (down the line) from his binary. or so the story goes...)
the original topic i brought it up on was "what will you trust your passwords to"? frienditto requires you to give them your password, which i wouldn't trust in the slightest. so if i had to give a tool my LJ password (like, say, the open-source DeepestSender extension for Firefox) i'd like to be sure that the code is open enough that i can see what it plans to do with what i give it.
you're correct in that opensource by itself doesn't mean "instantly secure" at least in the complex server realm, but it does mean i can trust it to be secure for small-scale clients i'm trusting my passwords to.
trust me, i've been at this business for a decade and a half, back before opensource was coined but when it was the only way to get anything at all. 3 opensource projects have had my name on them, and i've got 1 ready to go "open" and another in the planning stages.