Can we use p4 tickets somehow to solve this problem? Would it be possible for each user to log in once per "session" using a password that isn't saved anywhere, and retain permissions for that user with a ticket?
Obviously we shouldn't store passwords in cleartext or with bad encryption. But I wouldn't mind entering a password once a day (or a couple times) manually to get things started. Would requiring the password on each session should also get us around the password change issue? I'm pretty sure my IT dept won't allow us to store a password for the respository in our config files. Our IT department will not provide a special account for the server. Even read-only access is not secure enough. We need to prevent employees without access from *reading* files within parts of the repository for which they don't personally have access. The danger for us is the release of the IP, not the ability to modify the code. For us, and I'm sure many others, solving this issue will be essential to our use of reviewboard. On Sep 19, 8:37 pm, "Christian Hammond" <[EMAIL PROTECTED]> wrote: > This isn't a very usable solution, for a few reasons. > > First, we can't use the user's Review Board username/pass, because this > won't always correspond to the account on the Perforce server. Also, > passwords are one-way encrypted so that they can't easily be decrypted if > the database is accessed by a malicious user. > > Given that, we'd have to specify the user/pass to use on every operation. > Since Review Board pulls files from the Perforce server when generating a > diff, which may happen at any time, we'd have to store the user/pass in > plaintext in the database, which is horribly insecure. IT admins generally > wouldn't be okay with this, and it would just be irresponsible for us to > implement. We could do a sort of two-way encryption but this isn't really > much better. > > Yes, we are storing the repository account's password in plaintext, but the > general advice is to have a read-only user account or something so that if > someone has the password, they can't do anything too dangerous. It's also > far better than to have every single user's password available in plaintext. > > Also, if a user changes his username/password at a later time on the > Perforce server, or the user is removed from the Perforce server, all > associated review requests would become inaccessible. So storing user > account info for accessing the server has a lot of downsides. > > Christian > > -- > Christian Hammond - [EMAIL PROTECTED] > VMware, Inc. > > On Fri, Sep 19, 2008 at 5:16 PM, Daniel Wexler <[EMAIL PROTECTED]> wrote: > > > So, I think we already are using the official Perforce Python module. > > That's good (it makes my IT guys happy). > > > Why do we use the client and repository setting for the Repository > > instead of using a client/pass from the user? > > > I think my IT guys would be happy if we used the user's client/pass > > information when the server accesses the repository instead of a > > single, global user/pass. > > > Just poking around the code, how would I get the reviewboard user/pass > > inside scmtools/perforce.py:19? If I had folks set up their > > reviewboard account using their same user/pass as they have with > > Perforce, would it all Just Work (tm)? > > > On Sep 19, 5:00 pm, Daniel Wexler <[EMAIL PROTECTED]> wrote: > > > Has anyone explored the new Python bindings for Perforce? > > > >http://www.perforce.com/perforce/doc.081/manuals/p4script/p4script.pdf > > > > They seem to have functions for logging in to the server with a > > > specific user name and password from Python. Could we use this and > > > have the user's provide the Perforce user/pass as part of their client > > > info? > > > > On Sep 19, 4:43 pm, "Jeff Andros" <[EMAIL PROTECTED]> wrote: > > > > > it's not a pretty solution, but what about setting up multiple > > reviewboard > > > > instances, with different user credentials in each (one for each > > project > > > > you've got) then you only create accounts on the servers that theyr'e > > > > supposed to have access to. > > > > Jeff > > > > O|||||||O > > > > > Help me and the Leukemia and Lymphoma society fight blood cancers: > >http://pages.teamintraining.org/dm/tucson08/jandros > > > > > On Fri, Sep 19, 2008 at 4:30 PM, Daniel Wexler <[EMAIL PROTECTED]> > > wrote: > > > > > > I see an older discussion about the issue of Perforce security and > > the > > > > > need to put the P4 user and client information into the server: > > >http://groups.google.com/group/reviewboard/browse_thread/thread/d057c... > > > > > > Any update on this situation? > > > > > > My company is similarly concerned about this security issue and would > > > > > like a way of passing through the user's perforce credentials. Is > > > > > anyone actively working on this issue? > > > > > > We have a large company and have many internal security groups. > > There > > > > > have been issues in the past with "server" accounts that make the IT > > > > > department hesitant to set up a special Perforce account for the > > > > > server. > > > > > > Can someone explain why the server needs Perforce access in the first > > > > > place? Why not just upload the required information as part of the > > > > > user-side post-review script? > > > > > > BTW, I did install Windows NTLM authentication on my server using > > > > > mod_auth_sspi with no issues so far, which provides a modicum of > > > > > security. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
