Isn't it a tad goofy to worry about SSL in posting when it's just going to be sent in plain text through HTTP when the journal is loaded anyway?
2001-09-10 07:34 am (UTC)
Yeah, I can see that. Hrm. That raises the idea of SSL enabled journals as well.
At the very least, authentication should be SSL enabled. SSL enabling posting and viewing could be paid features? I know I'd pay for them.
It seems common for there to be two versions of application packages for which SSL is optional. You could build both logjam and logjam-ssl.
However, it seems preferable to simply require libcurl OR libcurl-ssl, link to libcurl.so (which might link to SSL or might not), and complain at runtime if the user tries to do something you can't do. If the user tries to make an SSL request and libcurl wasn't built for that, you'll pass the request to libcurl, it'll complain, you pass the complaint back to the user with an explanatory message. Is that possible?
2001-09-10 08:46 am (UTC)
Its not a curl issue, libcurl with ssl enabled is able to use ssl when needed, and not when not. Its not a problem. What is a problem is openssl across distributions, and dependencies within RPMS.
Mandrake Linux, as per the example above, puts and looks for the ssl libraries in /usr/lib. Red Hat Linux (in a more correct methodology) puts them in /lib. Hence, any ssl-enabled logjam rpms built on a Red Hat machine (all I immediately have access to) will auto-generate dependencies to the libraries in /lib, and Mandrake systems will look for those libs in /usr/lib, for the same dependency.
A potential solution would be to create a -mdk rpm set in addition to the Red Hat built set, however, I really want to avoid being distribution specific on my package if possible.
I'm also fairly confident that using rpm magic pixie dust I can make it look both places, or by forcing it not to autodependency check, but both of those options will take time to create, and I'll have to put Mandrake on a separate test box.
Making the default without ssl is a temporary solution. I've got two spec files currently, the default and -ssl. I just haven't posted the ssl enabled rpms (the current cvs, which is fairly old, is still ssl enabled).
2001-09-10 10:17 am (UTC)
the post has been updated to reflect the true reason why it broke on mdk. hey, i'm only infallible when the day ends with the letter a.
Yeah.. everything is as good as public, but this isn't supposed to be a secure service.
So what's your password? :)
Right now, there's no way to secure your password sending it to LJ; SSL/TLS will let you do that.
*cough* ./configure && make && make install
2001-09-10 11:38 am (UTC)
I think you just like being flamebait. Note that I was very specific to this being an RPM based issue.
2001-09-10 03:41 pm (UTC)
Too high CPU load...
as someone who has written SSL enabled client and server side apps, I'm not betting that the LJ servers will have enough extra CPU cycles to do SSL authentication any time soon.
The reason is that if the username/password is what is to be protected, then not only will this be required in every post, but in every HTTP request to view,say, your friends page which must verify that you are logged in. Isn't how this is done now is that the browswer caches the username/password, and resends it every time you make an HTTP request to *.livejournal.com? If you want to protect the paid users passwords, the LJ webservers will have to put every HTTP request over HTTPS.
That's a *huge* hit on already overburdened servers. Why not add SSL functionality when the server folk say they want to start doing it? Until then, it's just extra baggage.
2001-09-10 04:13 pm (UTC)
Re: Too high CPU load...
Now, this is where I step aside and say that while I know SSL theory, I know nothing about its code implementation.
I thought the current authentication was one-time for logins (using cookies after that) instead of browser caching login/password data (since not all browsers can)
Perhaps only a formal login would be ssl enabled? This would help limit load.
Also, I'm not pointing a gun at people and demanding that this be added. I just think its a good idea, and want to bring it up for consideration. :)
i brought up the aspect of using ssl back before i officially had development of the windows client. brad said that he had thought about it, but had no plans to do it in the near future.
so, at that point i changed the windows client to not store the plaintext password in the registry (simply obfuscating it a tad instead to prevent causal browsing) and to use the md5 hash'es instead. neither are "secure", but at least prevent casual grabbing of the passwords.
since the source for the windows client is openly available though, someone could easily look at the simple xor cipher and use the function to decode it to simple display a messagebox.. but at least it is more steps.
anyway, the point to this is that i doubt brad will be moving the server to ssl anytime soon.
2001-09-18 04:31 pm (UTC)
Possibly off topic, considering the entry subject matter, but I have little idea where else to make mention of it.
It could possibly be very helpful to actually mention the libcurl dependency in the "Requirements" section of README, in the source tarball. I remember nabbing the source some odd day and being stupified for a couple minutes over what I was missing.
With mandrake 8.0 that I justs put in today ..
And the it had problems .
Being new to linux I have know idea how to install with out it being a RPM. ( hope to some day lol)
If and when you do the RPMs for mandrake will you let me know .
2002-07-02 09:07 pm (UTC)
Re: Yep tried to install today
Me too...I had it installed back in April but had to reformat the harddrive Linux was on to correct a hard drive partition table error on my Windows drive. Now I can't get it to install at all. Oh well, guess I'm stuck using the web client when running under Linux.
FWIW, curl-config(1) is a relatively new feature that was added to the curl package, so Logjam doesn't build right with older curl 7.X installations .
2001-10-14 08:58 am (UTC)
Re: curl versions ..
It was added post 7.6 (IIRC). If you're using a distribution with that old of a curl implementation, you really should consider upgrading, either the distro, or curl.