Hi Dne Mon, 26 Jan 2009 18:47:31 +0100 (CET) "Joop Boonen" <joop_boonen@web.de> napsal(a):

I've checked out ~/.oscrc I saw that my password can be found in plain text.

As someone who would be able to read this file would be able to change packages that I have created. I'm rather worried about it. The package could easily be piggy backed with mall ware.

I'm wondering wouldn't it be possible to put an encrypted password? Or even better to work with ssh keys?

An other option would be that the password wouldn't be saved.

I also did not like this and I posted a patch in bugzilla [1] for optional usage of GNOME Keyring for passwords. [1]: https://bugzilla.novell.com/show_bug.cgi?id=460540 -- Michal Čihař | http://cihar.com | http://blog.cihar.com

On Mon, Jan 26, 2009 at 06:47:31PM +0100, Joop Boonen wrote:

I've checked out ~/.oscrc I saw that my password can be found in plain text.

This is nothing to be worried about per se -- as *long* as you are aware of the fact that it is stored there. In general, the home directory should be well protected also due to other secrets lying around there. ssh keys, browser passwords and other secrets are often stored on disk, and often not encrypted or not well encrypted.

As someone who would be able to read this file would be able to change packages that I have created. I'm rather worried about it. The package could easily be piggy backed with mall ware.

I'm wondering wouldn't it be possible to put an encrypted password? Or even better to work with ssh keys?

An other option would be that the password wouldn't be saved.

Here are some thoughts about this. I try to also cover other security-related concerns. Sorry about the long mail, but it is a rather complex topic. Regarding certificates: It is planned to check them starting with Python 2.6, which we get with 11.1/SLE11. Earlier Python versions didn't fully support this with the packaged modules. You can read https://bugzilla.novell.com/show_bug.cgi?id=405624 for the rationale why it wasn't too practical so far to add certificate handling with external Python modules, and why it seemed a better idea to wait until upstream has solved this (or rather, when the solution becomes available to us). Regarding password storage: If you think that passwords stored in another way than plain-text in a local file are more secure, I don't necessarily agree. Any secret needs to be stored somewhere, unless you want to enter it everytime you use it. The various ways to store the secret don't change the fact that it is stored. In fact, a false sense of security could be inferred. * Entering the secret every time is of course entirely fine, and albeit not practical for most people or use cases, requires little more than hacking the osc configuration parser to not store it to disk. It should be an easy patch, and I'll happily assist or give advice. Note that osc also saves a session HTTP cookie that it receives from the iChain proxy, which is used to considerably speed up the HTTP traffic; without this cookie, the client has to go through a painfully slow authentication process for each request that it does. Hence, it might be desirable to disable storing the cookie, too. * Storing the secret will almost always mean to put it to disk somewhere. Whatever kind of secret is used, like cookie, plaintext password, SSL certificate, the situation is always the same: It doesn't matter in which form it is put to disk. Encrypted storage (like encrypted SSL certificate) means that another secret (the encryption key) needs to be stored or entered every time again, it doesn't change the situation. About 5 years ago, when subversion was written, there were endless threads about this and it was discussed in great depth, how to store the passwords for HTTP access, whether using agents is feasible, et cetera. The outcome of these discussions always was that a local file mode 0600 is about as much as you can do, and it doesn't get any better from there. (Regarding agent usage, I think that just nobody bothered enough to implement something.) It is simply assumed that you have to ensure that the file is reasonably well protected. This can mean that you symlink the configuration file to a safe place on your machine (local file system, root password that is only known by you). It needs to be treated exactly the same way as ssh private keys. Setting OSC_CONFIG in the environment should also work. Note: the client is absolutely required to have access to the password in clear text, because that's the way that HTTP Basic Authentication works. (The same is true for Digest Authentication.) * Storing a base64 encoded password instead of plain text would have the advantage that in the occasional "looking over someones shoulder" situation the password cannot be read. That's what CVS did. It would be fully reasonable to implement this. However, even this can lead to the belief of false meaning of security. I'd bet that nobody would ever complain again if we did that - and it would prove my point. People are shocked when they see their password in plain text, and that's actually a good thing. Base64 encoding is no encryption; it is reversible. The same advantage (protection against haphazardly looking at the password) is achieved if the password wouldn't be stored inside .oscrc, but in a separate file, like subversion does it. * Using a password agent partly improves the situation, but again it doesn't help against people being root on the local box. Anyone being root on the local box can get the secret from the agent. An agent helps to have a file system that doesn't contain a plain text secret, so if the machine is stolen, it can't be recovered from disk. Especially with an automatic timeout it could be a viable compromise, offering some conveniency and some security. Agent *forwarding* via ssh could be an interesting thing, though. But does anyone think that ssh-agent (or gpg-agent) can be used to store opaque data chunks instead of ssh identities? I don't think so. From cursory look at the code it seems it's built to only work with ssh keys, which might also be due to the mechanism of key passing. One thing to consider is that making an agent mandatory would induce a too large hurdle for most users. Just look at how few people have a proper ssh agent set up. Many of the build service users wouldn't bother and simply don't use the build service. But an option for those people who care makes a lot of sense of course. I think the two principal options are: 1) HTTPS access + cleartext storage on safe filesystem 2) ssh access with (real) ssh keys A two-fold approach, as subversion does, offering 1) and 2), seems best to me. An ssh-key-based approach should likely be using real ssh and not trying to re-implement anything. Just like git does. Alleviating 1) with password managers like Gnome or KDE password manager would be very good, too. A problem with the build service password is that it is used for lots of other things. This makes it much more difficult to keep it secure, and not spread over all places, and that even though we don't have single sign-on either. It is unfortunate that the same password needs to be stored by browsers, scripts, developer's test machines, and other stuff. There should be separate passwords for some services, really. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development