?

Log in

No account? Create an account
new logjam RPMS - LogJam [entries|archive|friends|userinfo]
LogJam

[ website | LogJam ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

new logjam RPMS [Sep. 10th, 2001|10:18 am]
LogJam

logjam

[spot]
After much discussion towards the end of last week with evan & shacker, it was discovered that Mandrake puts its ssl libs in /usr/lib, instead of /lib, throwing off the RPM autodependencies for the ssl libs. I'd wager that other distributions do as well, so I redid the 3.0.0 rpms using curl & curl-devel instead of curl-ssl & curl-ssl-devel. Release 7 is SSL free.

Update: Ok, I was wrong. Here's why the RPMs don't work on Mandrake. To ensure binary compatibility between openssl 0.9.5 and 0.9.6, Red Hat upped the so.# on the libssl file. Mandrake just dropped openssl 0.9.5 altogether, and never bumped the so.#. They weren't required to, and likely, most distributions had no need to. But this is why the libssl dep failed for shacker, because it was looking for a libssl.so.2 when Mandrake had a libssl.so.0. I discussed with our openssl maintainer the possibility of looking for both .so.2 and .so.0, but we ended up agreeing that it was a very bad idea, since it would be impossible to guarantee that any given distribution would compile ssl with the same subversion or algorithms, and openssl is not binary compatible between releases. The answer is probably the same as the original answer: If you're using Red Hat, you're fine. If you're using Mandrake or another RPM based distro, you'll want to rebuild the curl-ssl SRPM, so that it can link against the correct version of openssl, install the curl-ssl and curl-ssl-devel that match your system, then rebuild the logjam-ssl SRPM (when it reappears, after licensing issues get straightened out) and install that. Its the only way to be sure. If there's enough demand, I'd be happy to host -mdk versions of the -ssl rpms, but I'm not going to build them myself.

And now, my original reasoning for using ssl enabled curl packages: I like security. Most of you probably do too, I know a lot of people enjoy the ability to do friends only or private posts, or to at least have the option available to them should they ever find the need. Unfortunately, when livejournal login information and content is sent plaintext across the <sarcasm> incredibly secure network known as the Internet </sarcasm>, its as good as public. Encryption is better security, IMHO, and SSL encryption is your friend. Currently, none of the livejournal clients are SSL enabled (to my knowledge, I haven't used the windows clients in eons) and the web update isn't HTTPS (or with the option to use it). I realize that using SSL encryption for authentication and posting would require development work on the LiveJournal servers themselves, and the clients would also have to add code for such functionality, but I think its worth it for privacy, and would also be a useful feature to help LiveJournal gain corporate/educational acceptance.

So I built the logjam rpms with curl-ssl, in the hopes that it would help lay a foundation for an SSL enabled LiveJournal.
LinkReply

Comments:
[User Picture]From: czircon
2001-09-10 07:29 am (UTC)
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?
(Reply) (Thread)
[User Picture]From: spot
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.
(Reply) (Parent) (Thread)
[User Picture]From: jnala
2001-09-10 07:52 am (UTC)
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?
(Reply) (Thread)
[User Picture]From: spot
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).
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: spot
2001-09-10 10:17 am (UTC)

update

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.
(Reply) (Thread)
(Deleted comment)
From: piman
2001-09-10 10:23 am (UTC)
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.
(Reply) (Parent) (Thread)
(Deleted comment)
(Deleted comment)
(Deleted comment)
[User Picture]From: tydel
2001-09-10 11:31 am (UTC)
*cough* ./configure && make && make install
(Reply) (Thread)
[User Picture]From: spot
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.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: pbrane
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.
(Reply) (Thread)
[User Picture]From: spot
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. :)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: visions
2001-09-10 05:54 pm (UTC)
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.
(Reply) (Thread)
From: zhixel
2001-09-18 04:31 pm (UTC)

A suggestion.

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.
(Reply) (Thread)
From: ex_candle321
2001-09-24 08:58 pm (UTC)

Yep tried to install today

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 .

candle
(Reply) (Thread)
[User Picture]From: five0xpres
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.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: driveontheright
2001-10-13 01:39 pm (UTC)

curl versions ..


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 .

$0.02,


_Michael.
(Reply) (Thread)
[User Picture]From: spot
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.
(Reply) (Parent) (Thread)