On 2009-10-02 14:08, Bob Archer wrote:
[chop]
>
> Some of this stuff also depends on what you are storing. Perhaps going another way would be better. For example, use NT Authentication to access your SQL servers rather than username/password. This way, the password isn't in the configuration file. I am sure there are similar LDAP type ways to deal with this for other technologies also.
>
[chop]
Seconded. Passwords for services are a relic from the 80s.
Buildbots and so on should have a collection of keys that are used
to build things. Between GSSAPI, NTLM, PKI, and ssh public keys,
there shouldn't be too many technologies left that need a
clear-text password. Your source-controlled configuration files
should tell you which accounts should do what and you should have
encryption keys on the side accessable only by the accounts that
need them, and a rotation policy in place to ensure you don't find
yourself using a 512 bit PKI key you generated 10 years ago.
Unfortunately, we've all been talking about how you shouldn't put
sensitive information into Subversion because we've been assuming
it's passwords. I'd be curious to know if someone has thoughts on
how to add client-side support for PGP encrypting files prior to
committing them to Subversion. I imagine a giant enhancement to my
current svn wrapper script to look at properties to determine key
lists for encrypting a file as I commit it. For those of us who
work on commercial software, it would be attractive to have all
source encrypted on disk at all times, including when it's in a
source repository, and such a feature would be an interesting
feature for Subversion.
--
Alec.Kloss_at_oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
- application/pgp-signature attachment: stored
Received on 2009-10-02 20:27:09 CEST